ACCESS VIOLATION semi-repetitive crash

[franco__]

Hi,

We encounter a semi-repetitive ACCESS VIOLATION crash while running our VB script in DIAdem 2020. Most of the time, after the crash DIAdem closes, some other times it just freezes. I tried 4 times to do exactly the same procedure (start the script, load the same data file through the script's GUI, put the same manual input in the same order) and the error messages for each time were:

First time:

21   10:27:17 Error:
     Error while executing "("C:\[personal folder]\OAQ\src\OAQ_main.VBS")" command
     Error type: ACCESS VIOLATION
     Error address: 000941CE
     Module name:oleaut32.dll

Second time:

30   10:41:35 Error:
     Error while executing "SUDDlgShow("oMPSDialog","C:\[personal folder]\OAQ\src\modules\UserInterface\MI_UserInputParameters.SUD",???)" command
     Error type: ACCESS VIOLATION
     Error address: 0002D414
     Module name:ntdll.dll
31   10:41:35 Error:
     Error in <MI_Parameters.VBS> (Line: 45, Column: 4):
     Error while executing "SUDDlgShow("oMPSDialog","C:\[personal folder]\OAQ\src\modules\UserInterface\MI_UserInputParameters.SUD",???)" command
     Error type: ACCESS VIOLATION
     Error address: 0002D414
     Module name:ntdll.dll
32   10:41:35 Error:
     Error while executing "("C:\[personal folder]\OAQ\src\OAQ_main.VBS")" command
     Error type: ACCESS VIOLATION
     Error address: 000259E2
     Module name:ntdll.dll

Third time:

37   10:50:34 Error:
     Error while executing "("C:\[personal folder]\OAQ\src\OAQ_main.VBS")" command
     Error type: ACCESS VIOLATION
     Error address: 994FF000
     Module name:DIAdem.exe

Fourth time:

46   10:52:56 Error:
     Error while executing "("C:\[personal folder]\OAQ\src\OAQ_main.VBS")" command
     Error type: ACCESS VIOLATION
     Error address: 000941CE
     Module name:oleaut32.dll

Most of the time the crash happens in the same "part" of the code (I cannot really quantify how many lines because of many nested functions), and around 40-50% of the time in the same line as shown in case 2 (SUDDlgShow...).

A few times I tried using the debug function, putting breakpoints around the area where the crash occurs, and then it worked OK. Also, sometimes it works OK, but then I re-run the same script and data file (without restarting DIAdem) and it crashes.

Could you please orient me on how to solve this problem?

Thanks a lot,

Franco

[Brad_Turpin]

Hi Franco,

First off, I'm sorry-- this is an ugly debugging environment to be stuck in.  The error messages you posted seem to focus on the SUDDlgShow() command and then possibly an ActiveX call in the script.  What sort of behavior do you get if you temporarily comment out any calls to launch SUDialogs?  Do you have any CreateObject() commands in your VBScript or your SUDialog?  Or any embedded ActiveX controls on the SUDialog?

Are you able to submit your VBScript and SUDialog for me to look through its commands?

Brad Turpin

Principal Technical Support Engineer
NI

[franco__]

Hi Brad,

Thanks for your reply. I respond to your questions:

1. I haven't tried commenting the SUDDlgShow command, I'll try that next. I had tried something similar but not the same: in my script I can choose if I want to do the manual interaction (which calls the dialogs), if I say I don't want it works OK.

2. I don't have any CreateObject() commands

3. I don't think I have ActiveX controls, except the ViewConnector in a previously called SUD. By the way, in the previous script version I didn't have the ViewConnector object, maybe this is the offending part?

4. I include to this the offending script and a couple extras for reference. The flow is as follows:

• User runs OAQ_main (not included)
• OAQ_main does some pre-processing (including creating and populating the oTraveller object)
• OAQ_main calls ManualInput (attached file)
• ManualInput calls MI_CircuitsAndQuenchStart (attached file)
• MI_Circuits... adds a view sheet (attached file) and puts a SUD in one of the areas (attached file). This SUD has a ViewConnector object.
• After MI_Circuits... gets the view data, it loads a different, empty SUD into the view sheet. This SUD also has a ViewConnector object.
  • A few times the error happens here, in MI_Circuits around lines 105-110
• ManualInupt calls MI_Parameters (attached file)
• MI_Parameters creates the oMIParameters object based on the class cMIParameters (attached file)
  • The error often occurs when MI_Parameters tries to call the MI_UserInputParameters SUD, around line 45

[Brad_Turpin · Accepted solution]

Hi franco,

Before we look deeply into the possibility of the View connector being the cause of your error, I'd like to pursue one other thing that caught my eye in the files you posted.  The following files contain Interaction commands:

InteractionOn()            MI_CircuitsAndQuenchStart.VBS

InteractionOn(Msg)     MI_Parameters.VBS

InteractionOff()            MI_ViewDialogs.SUD

The "MI_Parameters.VBS" call is the least problematic, because passing a message string as a parameter in the InteractionOn() command results in a non-modal pop-up dialog that reminds you to manually click to stop the interaction.

The "MI_CircuitsAndQuenchStart.VBS" call is more problematic, because all it does is enable the "End Interaction" icon in each panel, which users can completely miss.  The danger is that if you run the same script again without first allowing the first script to finish, you can end up with multiple instances of the same script in a "script stack" of paused scripts, such that the next time someone clicks the "End Interaction" icon, the FIRST script that was paused will wake up and continue, NOT the latest script that was started.

The "MI_ViewDialogs.SUD" call is mainly problematic if you're trying to run that dialog modally, in which case the InteractionOff() will never properly end the desired script instance in the InteractionOn() state.  If you call the dialog as a non-modal dialog, either free-floating or bound to a VIEW Area, then this InteractionOff() command has a chance at ending the desired paused script instance.  Still, you're counting on the user remembering to end the interaction state at the right time by clicking that button.  In my opinion the InteractionOn feature is rarely worth the risk it incurs, especially in a larger application.

I would actually advise you to avoid the InteractionOn() calls entirely.  If you have an SUDialog embedded in VIEW, then you can use that button click event to run the next leg of the script, as opposed to resurrecting the paused script instance from its limbo state.  Again, the issue is that if you ever start a script and pause it, but fail to end its interaction trance, then re-run the same script, squirrelly-ness ensues.  This can easily happen when you run the script and the larger application or DIAdem itself encounters an error after the InteractionOn() call but before the end of the interaction trance.  You decide to start over by running the main start script again, but you're not actually starting over with a clean slate...

All that said, the fact that you're getting OLE/ActiveX mentions in at least one of your access violation errors does make me think that your VIEW connector is involved at lest some of the time.  If you're programmatically inserting a SUDialog with a VIEW connector after an Interaction pause, then you could easily get a collision between script instance N waking up and trying to continue when script instance N+1 has run and changed various object states/references.  My guess is that these two things are working together to build your crash.

I think it's also interesting that most of the errors you posted occurs when running the "OAQ_main.VBS" script, which I don't have access to yet.  There may be something else in there that is causing trouble...

Brad Turpin

Principal Technical Support Engineer
NI

[franco__]

Hi Brad,

Thanks for the reply. I use the InteractionOn because I think it's the best way to request input from the users, in particular when asking to identify an event or a range of time of interest. I included the embedded non-modal dialogs in this version because I thought it could give some feedback to the user of what they are doing. 

For this particular bunch of errors, DIAdem crashed after each time the error happened, and I pressed the correct button while doing interactions, so I don't think previous interactions clashing are the culprit.

From what you are saying the embedded non-modal dialogs + interactions seem to be a liability, so I'll look into how to remove them as much as possible. I have two follow-up questions regarding this:

• Is there a way to detect if there is an active interaction, for example before running the script again?
• What would you suggest to replace the Interaction functionality?

Regarding your comment about OAQ_main: I attach it to this reply. I think it's going to generate more questions than it will answer, because this script essentially calls many other scripts and functions, and also some user commands. If you are interested I can find a way to share the full code, probably through GitLab. I know where the error happens because I log the main steps of the script, for example:

**** DIAdem START Version: 20.1 on 08-Oct-21 at 10:42:20                        
33   10:42:22 Info:
34   Loading file "C:\Users\Public\Documents\National Instruments\DIAdem 2020\Data\EXAMPLE.TDM" ...
35   10:42:22 Info:
36   File  'C:\Users\Public\Documents\National Instruments\DIAdem 2020\Data\EXAMPLE.TDM ' loaded.
 
***************************************
OAQ start, 08/10/2021 10:49:56
Welcome, user FRANCO__
File 1/1 -- Processing: [datafile].tdms
File 1/1 -- Loading TDMS file
File 1/1 -- Loading XLSX parameters file
File 1/1 -- General OAQ parameters found in the XLSX parameter file
File 1/1 -- Loading previous OAQ file for the manually input options
File 1/1 -- Creating output groups and channels
File 1/1 -- Report table: Triggers
File 1/1 -- Detecting protection: QH and CLIQ
File 1/1 -- No QH discharge
File 1/1 -- No CLIQ discharge
File 1/1 -- Manual inputs
File 1/1 -- Selection of circuit set up and quench start time
File 1/1 -- Time of quench: -0.0214 s
File 1/1 -- Quenched circuit: OC
37   10:50:34 Error:
     Error while executing "("C:\[personal folder]\OAQ\src\OAQ_main.VBS")" command
     Error type: ACCESS VIOLATION
     Error address: 994FF000
     Module name:DIAdem.exe
**** DIAdem START Version: 20.1 on 08-Oct-21 at 10:51:02                        
38   10:51:03 Info:
39   Loading file "C:\Users\Public\Documents\National Instruments\DIAdem 2020\Data\EXAMPLE.TDM" ...
40   10:51:03 Info:
41   File  'C:\Users\Public\Documents\National Instruments\DIAdem 2020\Data\EXAMPLE.TDM ' loaded.
 
***************************************
OAQ start, 08/10/2021 10:51:12
Welcome, user FRANCO__
File 1/1 -- Processing: [datafile].tdms
File 1/1 -- Loading TDMS file
File 1/1 -- Loading XLSX parameters file
File 1/1 -- General OAQ parameters found in the XLSX parameter file
File 1/1 -- Loading previous OAQ file for the manually input options
File 1/1 -- Creating output groups and channels
File 1/1 -- Report table: Triggers
File 1/1 -- Detecting protection: QH and CLIQ
File 1/1 -- No QH discharge
File 1/1 -- No CLIQ discharge
File 1/1 -- Manual inputs
File 1/1 -- Selection of circuit set up and quench start time
File 1/1 -- Time of quench: -0.0237 s
File 1/1 -- Quenched circuit: OC
File 1/1 -- Retrieving parameters from previous OAQ file
File 1/1 -- Previous OAQ file parameters incomplete
File 1/1 -- Manually input test parameters
File 1/1 -- Temperature guess: 1.9 K, from: extension
File 1/1 -- Opening parameter input interfase
**** DIAdem START Version: 20.1 on 08-Oct-21 at 10:51:53                        
42   10:51:55 Info:
43   Loading file "C:\Users\Public\Documents\National Instruments\DIAdem 2020\Data\EXAMPLE.TDM" ...
44   10:51:55 Info:
45   File  'C:\Users\Public\Documents\National Instruments\DIAdem 2020\Data\EXAMPLE.TDM ' loaded.

That's the logfile for two of this crashes, the first one with a notification of the type of error (at number 37) and the second one without (just before the last DIAdem start).

Thanks a lot for your help!

Franco

[franco__]

I removed all embeded SUDs in the View and this solved the problem. It's been a couple of weeks of testing and it seems to work. Thanks for the help!