Diadem crashing - dacasr.dll

[cowbreath]

I have an installation of Diadem that runs a script which monitors a directory for the existence of files and processes them accordingly.  If no files exist, the script sleeps for 1 second and checks for files again. This script runs constantly.

Periodically (once every 3-4 days), Diadem crashes. Windows identifies the faulting module as dacasr.dll. I have attached a screen capture of the Windows event viewer from when the crash occurs.

I have an installation of Diadem on a second PC which runs the same script and this second PC has never experienced a crash.

Has anyone experienced this error? Any recommendations for solving this crashing problem?

Version Information -
Diadem 9.10.2260 TDM Service pack 2
Windows XP 5.1.260 Service pack 2

thanks!

[StefanR]

Maybe it has something to do with DIAdem's virtual memory mangement.

You might want to try this:

- check free dics space

   You can see where DIAdem tries to put its temporary file when closing all window (windows>>close all). Then go to Settings>>Memory Management...>>Data area...  -> 'Path for....'

- tweak memory management by not allowing DIAdem to write. Go to the same dialog and set the memory reserve to 1 kByte.

Stefan

[Twigeater]

Hello!

Did you install a DIAdem 10.1 or LabView 8.x (I don't no the exact version) on the computer with the problem and not on the other one? I guess yes!

If you look on the DLL version in the screenshot you see a 10.1.1.2254. This shows that the USI, the DIAdem Data interface, seems to be in a newer version than the DIAdem you are running. I like to name this situation a DIAdem 9.5 . The reason is that today DIAdem is splitted into to parts: The DIAdem and the USI. The USI is shared between DIAdem and LabView and not version-controlled. If you install a newer USI version by installing DIAdem or LabView, the older one is replaced and the new and the old DIAdem will use the same new USI. You can check it on your two computers in the info dialog of DIAdem. There are the two versions for DIAdem and USI.

Before you ask: As I know is there no offical way to get back a 'clean' 9.1 DIAdem.

Matthias

[cowbreath]

I do not believe that LabView 8.? or Diadem 10.1 have been installed on the problem machine. The version number for dacasr.dll is 10.1.1.2254 on both machines. The USI version number stated in the "About DIAdem" box is 1.1.1.2254 on both machines.

Is this USI version incorrect for version 9.10.2260 of DIAdem?

[Brad_Turpin]

Hi cowbreath,

DIAdem 9.1 SP2 installs USI 1.1.1.2254, so that looks like a healthy match.  The symptoms you describe sound very much like a resource leak-- most likely a memory leak.  That may be happening in DIAdem or elsewhere in the system, and if it happens elswhere in the system it may be affected by DIAdem running a VBScript or it could be independent.  I assume if you leave that computer running for 3 days without starting DIAdem at all that it does not crash, right?

I have a wacky debugging suggestion which could also serve as an ugly but potentially effective workaround.  Have your VBScript keep track of the absolute run time and after 1 hour programmatically launch another DIAdem instance and release the current DIAdem instance.  You can configure your DIAdem to always run your VBScript when it launches, or in your launch command you can provide a /C DOS command extension to specifically launch a new DIAdem instance which runs your VBScript as soon as it comes online.

DosCmd = """" & ProgramDrv & "DIAdem.exe"""
DosExt = """/CScriptStart('" & AutoActFile & "')"
Call MsgBoxDisp("Script Executing", "MB_OKCANCEL", "MsgTypeNote", 0, 5)
IF MsgState = "IDCancel" THEN AutoQuit
Call ExtProgram(DosCmd, DosExt)
Call ProgramExit

'DosCmd = """C:\PROGRAM FILES\NATIONAL INSTRUMENTS\DIADEM 10.1\DIAdem.exe"""
'DosExt = "  ""/CScriptStart('C:\PSE\Useful VBScripts\Recursive DIAdem.VBS')"""

Note that this technique will NOT work if you have DIAdem-DAC,
Brad Turpin
DIAdem Product Support Engineer
National Instruments

[cowbreath]

Brad,

Thanks for the ugly but potentially effective workaround. I will try it.