referenced memory could not be read

[CDreike1]

My program uses the Initialize Keyboard.vi and Acquire Input Data.vi's to check for keyboard input.

The program acts correctly and normally. No errors until the exit.

On exit program the provides a pop up that states:

Application name.exe - Application Error

The instruction at “0x7c911669” referenced memory at “0x6e75533a”. The memory could not be “read”.

Click on OK to terminate the program.

See image below.

Per the other messages on the board regarding this sort of error, I'm guessing my keyboard access is the problem.

Do not know what to do about this.

Can anyone point me in the right direction?

Thanks,

Chris

[TroyK]

Are you closing the reference before exiting the VI?

Not that it should be throwing nasy errors for something like that.

[rolfk]

It's pretty easy to determine if this is the cause of the troubles by simply disabling the call to those VIs in your application. Wrap them in a Conditional Disable structure and implement some dummy operation in the other case where necessary and try again. Does it still crash?

The error you see is a very generic error. The keyboard VI could be the culprit, I wouldn't know, as I don't use it, but stating that it is, is a tall call, without verifying it. It could be just about anything in your program, and if there is anything else in your application that uses the Call Library Node and doesn't come with LabVIEW out of the box, that would be about 500 times more likely to be the cause of this error.

[CDreike1]

Thanks Guys,

I have made sure that I close all references.

I have also eliminated the keyboard items to no avail, Its got to be something else.

I'm using the DAQmx vi's. I make sure that after each read or write that there is stop. Upon exit there is a clear. I've tried with and without the DAQmx clear vi.

I'm still stuck.

Any other ideas?

Thanks,

Chris

[rolfk]

Look for any other Call Library Nodes, especially in VIs that do not come from NI. Not saying that NI couldn't mess up sometimes, but they do usually know what they are doing. Many others interfacing to external shared libraries with the Call Library Node however don't really know. And they are happy when it doesn't immediately crash anymore during the call assuming all the problems have been solved. In reality configuring a Call Library Node to not immediately crash anymore during the call is trivial in comparison to make it work always for every possible case and without some seemingly unnoticed memory corruption.

Once you close VIs or LabVIEW however, those memory corruptions surface, as LabVIEW goes through all its allocated memory blocks to deallocate them properly before exiting. And then stumbles over the corrupted memory blocks that contained at one point valid values.

[TroyK]

Believe it or not I got an almost identical error last night when I closed down LabVIEW. Nothign to do with a compiled exe or keyboard functions.

Maybe try repairing or reinstalling the LabVIEW runtime engine and whatever other modules your code may be using.

[CDreike1]

Thank you Rolf and Troy,

I am using only NI VI's from LV-2010.

I suppose I could try making a copy and compiling in LV2011. Maybe that is my next course of action after our holiday next week.

Since we have 2 target systems here, I tried on the other one. The code exits without problems. The difference is that the second system is running XP SP-2 rather than SP-3. Maybe something to do with SP-3? I rebooted the SP-3 machine just in case, also no improvement.

Today I created an installation with the 2010 run time engine, installed and ran the program rather than simply running the .exe from my jump drive. The installed program has the same exit problem.

Other than SP-2 versus the SP-3 versions, I'm not sure what to think.

Any thoughts?

Regards,

Chris

[TroyK]

Did you uninstall the LabVIEW runtime on the problem computer before running the installer you created?

If the installer detects that the LabVIEW runtime it needs is already installed it does not reinstall, it skips it.

You may need to repair or uninstall/reinstall the runtime engine.

If the target computer is just for testing, I would suggest to completely uninstall all NI software, restart, and then run your installer.

That's how I test my installers to make sure they have everything they need in them.

[CDreike1]

I have now recompiled the program in LV2011. There is no change. The program operates normally until exit and then provides the following message, a little different wording however looks to be about the same problem as in LV2010:

Program Name Crash Reporter

We apologize for the inconvenience

Progam Name 1.0.0.0 encountered a problem and needs to close.

Exception Access violation (0xC0000005 at EIP=0x7C911669

Version 1.0.0.0

A local copy of the error report was saved in location: LabView Data Folder

The error reports are attached in a zip file.

The LOG file says:

####
#Date: Tue, Jul 10, 2012 10:29:41 AM
#OSName: Microsoft Windows XP Service Pack 3
#OSVers: 5.1
#OSBuild: 2600
#AppName: Auto_Clutch_Test_V2011
#Version: 11.0 32-bit
#AppKind: AppLib
#AppModDate: 07/10/2012 16:44 GMT
#LabVIEW Base Address: 0x30000000

Possible path leak, unable to purge elements of base #0

If anyone has some ideas short of reloading Windows...

Thanks,

Chris

[TroyK]

The first step is to try to narrow down what is causing the problem.

Is it only happening on that one target computer or does it happen on others?

If it is only on one computer then that would suggest perhaps a runtime component installation issue.

If it is happening on all computers you try it on then proceed to the following:

Disable sections of your code (using diagram disable structures), compile and then test again.

If the problem disappears after disabling a section then narrow it down a little further until you can work out exactly where the problem is.