• State Verified Answer
  • Replies 8 replies
  • Subscribers 14 subscribers
  • Views 4428 views
  • Users 0 members are here
Related

Agilent Knowledge Portal

Find maintenance, best practice, and troubleshooting articles.

Agilent Knowledge Portal

MassHunter Crash/Hang

reesegar

I am currently trying to setup a GC system and am having issues with MassHunter Acquisition.  I am trying to setup a parallel system to one that we are currently running. The new system is  6890N/7697A HS, it does not have a MS. I am trying to use MassHunter to run the system since our other system is 7890B/7697A/5977A and would like to keep the same workflow for acquisition and data analysis. I have been working with Agilent to find the cause but thought someone in the community might have seen this issue before and could help also.

 

Information for the system:

6890N version: N.06.07

7697A version: A.01.06

MH Aq version: B.07.05.2479  23-Aug-2016

PC: HP Z220

OS: Win 7 (x64) Pro Service pack 1

RAM:20GB

excel installed

MS Qual version: B.07.00

MS Quant version: B.08.00

Connections Setup (Local connection): PC => switch => HS/GC

 

The MHInstall.LOG file has an error, but IQTools system verification tool shows all PASS except for MassHunter Aquisition GCRC.dll, which is an installed "patch" I received from Agilent so that the 6890N FID signal was saved correctly. Below is the error and the invalid file.

 

MHinstall.LOG Error:

“InstallShield 16:52:12: Error extracting ISBEW64.exe from ISRegSvr.dll”  

 

Invalid Files :
Full Path                                Installed Version              Expected Version              Reason
C:\GCMS\msexe\gcrc.dll      7.5.1.12                            7.5.0.2479                         Checksum Mismatch,Version Mismatch

 

Below are a list of things that I noticed in the software and on the instruments when the error occurs.

 

1.    The mslogbook does not show any connection errors. When the error occurs it does not have any entries, passed the time of the crash, until I restart MassHunter Acquisition.

2.   The headspace and GC do not seem to notice that MassHunter Acquisition has crashed.  If I do not select "close program" in the Windows error window, they both complete all of the runs in the sequence that was running when the software crashed. For example last night it crashed after 25 vials, I watched the GC and Headspace complete the sequence with vial 66 when I got in this morning and neither showed an error.

3.   The GC "remote" light stays ON even after the software crashes. When I restarted MassHunter Acquisition the "remote" light flashes off then back on quickly when Acquisition loads and is initializing the instruments.

4.   The GC shows "signal 1 buffer full", but this is only after I finally select "close program" in the Windows error window.

 

Below is a list of things that I have tried to resolve the issue.

 

1.   Tried both NIC cards on the PC in case it was a connection issue.  It doesn't seem to act like a connection issue since the MassHunter logbook does not show a lost connection.    

2.   Created new sequences from "default" sequence.

3.   Re-Created acquisition method from "default" method.

4.   Ran "repair install" from MassHunter installation disk.

5.   Un-installed/Re-installed MassHunter following installation instruction located on the install disk. Renamed old MassHunter folders to .OLD before re-installing MassHunter.

6.   Re-installed MassHunter again this time using the PC recovery disk included to start with the initial "clean" image of the PC before re-installing MassHunter. 

7.  Verified multiple settings and system files in the operating system

 

Are there any ideas on resolving this issue? I am running out of ideas to try and am thinking my next solution would be to uninstall MassHunter and run the system using Open Lab CDS Chemstation Workstation and changing my workflow and my LIMS workflow.

 

Below is the Windows error that keeps occurring during a sequence. This error does not happen consistently, I see the error after 96 vials, 1 vial, 25 vials, 9 vials etc. The error does not occur at the same "Time of Day".

 

Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: msinsctl.exe
Problem Signature 02: 7.5.0.2479
Problem Signature 03: 57bccd24
Problem Signature 04: mscorlib
Problem Signature 05: 4.7.3062.0
Problem Signature 06: 5ab95126
Problem Signature 07: 331
Problem Signature 08: 10
Problem Signature 09: System.ArgumentException
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

 

At the same time the above error occurs there is a .Net error created in the Windows system logs, shown below.

 

EventData:

Application: msinsctl.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.ArgumentException at System.ThrowHelper.ThrowArgumentException(System.ExceptionResource) at System.Collections.Generic.Dictionary`2[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089],[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].Insert(System.__Canon, System.__Canon, Boolean) at Agilent.Analytical.GC68xx.RCWrapper.Reporting.ReportType.GetParameterDictionary() at Agilent.Analytical.GC68xx.RCWrapper.RCProcessIF.GetIcfResourceProperty(System.String, Agilent.RapidControl.KeyValueInterfaces.IRCKeyValue ByRef) at Agilent.Analytical.GC68xx.RCWrapper.RCProcessIF.GetResourceProperty(System.String, Agilent.RapidControl.KeyValueInterfaces.IRCKeyValue ByRef) at HIA.GC68XX.GCGetPostRun() at HIA.GCRC.GET_RUN_LENGTH(Boolean ByRef) at HIA.Runctl.UpdateRunTime(Agilent.MassSpectrometry.CommandProcessor, Boolean) at HIA.Runctl.runClock_Tick(System.Object) at System.Threading.TimerQueueTimer.CallCallbackInContext(System.Object) at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.TimerQueueTimer.CallCallback() at System.Threading.TimerQueueTimer.Fire() at System.Threading.TimerQueue.FireNextTimers() at System.Threading.TimerQueue.AppDomainTimerCallback(Int32)

 

 

 

Thanks in advance for any help and ideas

Parents
  • 0

    Hello reesegar,

    Do you have the SR1 installed for MassHunter Acquisition B.07.05 (from the acquisition software, go to "Help/Review Revision History")? If not, I strongly suggest to install it. You should also upgrade the 7697A firmware to the current version A.01.08.1.

    You can try to configure another instrument with only the GC to see if the acquisition software will launch properly or if you will have the same error. If you get the same type of error, the GC Drivers should be updated to version B.01.04. I can provide you further instructions about updating the GC Drivers, just let me know.

    You can also try to configure an offline instrument with MassHunter Acquisition. I would definitely try that to see if the software launches properly with an offline instrument: when in the Agilent GCMS Configuration, configure an instrument but check the box "Offline Instrument" for that instrument.

    As for the logging suggested by nickbharden, you need to type SLOG 1 in the command line to enable the function and type ENDLOG to close the logging. The log file will then open in the software as a text file.

    Hope it helps, let me know if you have any questions.

    Rejean

  • 0 in reply to rejean_neron

    Thank you Rejean and Nick for the suggestions.

     

    I did not have SR1 installed so I made sure to update that. For the 7697A firmware I do not see that version on the Agilent site. https://www.agilent.com/en-us/firmwareDownload?whid=41189 but it looks like the site has not been updated since June 2014? Is there a different location for firmware files now?

     

    I did try one test last night and using the same instrument configuration I created a method that injected automatically with a GSV instead of using the headspace. The sequence did not complete (33 of 66 runs) but there also were not any of the error messages noted above. When I got in this morning the software was still in the sequence and was waiting for a run to start but the GC did not show that a sequence was in progress, it did still have the "remote" light ON. The mslog does not show any connection loss. Its almost like the GC and software at some point came out of sync but not due to the connection?

     

    Thanks again for the help,

    Garrett

  • 0 in reply to reesegar

    This is very interesting, you've done a lot of excellent troubleshooting--definitely a commendation on that, I am sorry for this frustrating issue.

     

    The test you did with the valve/immediate start injection eliminates the possibility that the headspace is involved. I suspect that we do have a problem with the connection of the GC to the acquisition PC. I recommend checking in the Windows Event Viewer log for GC driver error messages.

     

    For Windows 7:

     

    Click Start > Control Panel > System and Security > Administrative Tools.
    Double-click Event Viewer.

     

    Select Windows Logs > Application on the left. If you right click on this and choose "Save All Events As" you can export the application event log and send it to us for review (if you want to.)

     

    Anyway, left click on Application and wait for all the entries to load. Once they do, right click on the Source column and choose "Sort events by this column." Look for entries with source AgGC7890Drv, this is the GC driver and it sometimes puts useful stuff here. You will see normal messaging when the connection is established/closed, but there may be some diagnostic messages recorded if the connection is being closed abnormally.

     

    If you can, please also send us a sequence_info.log for a sequence that is interrupted. This log is written to d:\masshunter\gcms\1\ and for a sequence IN PROGRESS the log file is sequence_info.log. If the sequence successfully completes, it will be renamed to {timestamp}-Sequence_info.log. If it does NOT complete (either aborted manually or due to error) this log file will not get time stamped and will be over written the next time a sequence is started.

     

    As an aside, we fixed this recently in the latest revision (very happy about this.) Now we rename any untimestamped sequence_info logs when the application is started or when the sequence is started.

     

    The sequence.log contains information about what the sequence table contains: vial location, method name, sample name, data file name, etc. The sequence_info.log is a step-by-step log of the sequence execution with approximately 12,000 lines per injection. If the problem occurs while the GC is moving vials, making injection etc we will see it. If the error occurs as the GC is acquiring data, then our command processor is busy and we will not see the error. It will still be useful to review this log.

     

    Thank you,

    Alex Graettinger

    Product Support Engineer for GC/MS Data Acquisition

  • 0 in reply to graettin

    Alex,

     

    Thank you for the suggestions. I looked into the event viewer and I do not see any AgGC7890Drv since 6/10/19. Which is interesting since it looks like this event is created each time the connection is made and I have definitely been running the instrument as well as restarting the PC since the 10th. I have attached a sequence_info log for you as well as one of the SLOG's mentioned in an earlier post. This SLOG is from when the GC stopped at 33 runs and no CLR20r3 error, anytime the CLR20r3 error shwoed up I was not able to ENDLOG so this is the only one I was able to get that was completed.

     

    I think the issue might be resolved but I am still running sequences to make sure. Below is what I have tried since the last post and making a method without the HS.

     

    1. Configured a new instrument that did not have the HS at all so it was just the GC.

    2. Ran a sequence and it stopped at 33 runs like the sequence I had tried with the GSV. This pointed towards the drivers, per Rejean, so I updated the drivers to B.01.04.

    3. I ran a total of four 50 line sequences on this new configuration after the driver update and they all stopped at 33 runs. None of them showed the CLR20r3 errors. MassHunter was  waiting for the run to start on the 33rd run each time and I had to "Stop" the sequence in MassHunter to do anything. On one of the sequences I was able to watch the GC at run 33. The software setup the new data file and transferred the method to the GC. The GC flashed like it accepted the method and the setpoints showed that they were not "ready" like normal when the new method is loaded. Then the GC just flashed and moved out of "sequence in process". MassHunter just waited for the GC to start there was no error and I had to "Stop" the sequence.

    4. the 33 runs isn't perfect but at least it was repeatable so I went back to the HS/GC instrument and started a sequence to see if it would behave the same. It has not shown the same problem. I have been able to complete a 50 run sequence Sat/Sun a 108 run sequence Sun/Tues and another 108 run sequence Tues/today. 

     

    With this said it seems like the updated drivers fixed the issue. I am still not sure why the GC configuration would only go to 33 runs and that it was repeatable for 4 sequences. Since I will be using the headspace and GC, and I am not seeing  issues with the sequences I am assuming it is stable enough to think about validation. 

     

    If you have any other ideas or suggestions please let me know. Do you think I should still like to take the Headspace firmware to A.01.08? Is there is another place to download the firmware since this link https://www.agilent.com/en-us/firmwareDownload?whid=41189 only has A.01.06.

     

    Thanks,

    Garrett

    attachments.zip
  • 0 in reply to reesegar

    Hello Garrett,

    Yes you should update the HeadSpace sampler firmware to the latest version which is A.01.08.1. The firmware file is attached.

    Best regards,

    Rejean

    A.01.08.1.zip
Reply Children
Was this helpful?
Privacy Statement
Terms of Use
Contact Us
Site Help