Does the Runtime engine store crash logs anywhere?

[BertMcMahan]

I have an executable that's crashing on a deployed computer. The same executable works fine on the dev machine. I can reliably reproduce the crash on the user's computer, but following the same steps in the dev machine do not produce a crash (even on an exe running in the dev environment).

It's a large Actor Framework project, and I have error logging tools built in, but they're not getting called when the program closes, leading me to believe it's an RTE crash.

I've looked around and I have found lots of discussion about where the LabVIEW dev environment puts crash logs, but not the RTE. Is there a spot for RTE crash logs? If it doesn't report that automatically, is there any way to run them "verbosely" to report crashes?

I'm going to continue looking for a bug in my code, but the AF has a pretty well defined error/shutdown sequence that doesn't appear to be triggering. (FWIW, I added logging code to my top-level Actor's Stop Core.vi override and I'm not getting data when the crash happens.)

[mcduff]

Is there anything in ~\Documents\LabVIEW Data\LVInternalReports

[IlluminatedG]

If you go to %temp% in file explorer you should see some logs starting with the app name.

[Kyle97330]

You should also use the Windows Event Viewer to see if anything gets logged there the same time the application crashes.

[BertMcMahan]

Thanks for the tips. %temp% had a little bit of info there, but it was mainly just something about starting up the process. Nothing interesting. There wasn't anything in LVInternalReports.

The Windows Event Viewer did show some stuff, though. There were a couple dozen different events. The first two just said "Application error" with red X's and a few random codes that don't seem to have particularly interesting results on Google. Then there are a couple dozen other "App crash" events, including several other programs. Not sure what's going on there. One Google result led me to someone claiming a faulty memory stick caused a similar crash in several unrelated programs.

Is there a good way to decode these Event Viewer messages?

Edit: I suppose I should actually mention the errors if I want some help, lol.

I get two- the first is Event ID 1000 with exception code 0xc000001d. Not much other data. The second is Event 1005, which gives a long message about "Windows cannot access the file for one of the following reasons: there is a problem with the network connection, the disk the file is stored on, [...]. Windows closed the program [program name] because of this error."

Unfortunately, the "File:" section is blank. It doesn't give me any data about what exact file it's trying to open.

If I somehow passed an empty path into an Open File function, I'd just get a regular error, not an RTE crash (I'd hope).

Also, I've confirmed this happens on two separate machines now apart from the dev machine, so it's not looking like a specific computer issue.

[BertMcMahan]

Bumping this thread as the issue still isn't resolved.

When looking at the Event Viewer logs, there are entries for "Faulting module name: unknown", "Faulting module path: unknown", "Faulting package full name: [empty]", and "Faulting package-relative application ID: [empty]".

I'm not really sure what the "Faulting module" is referring to. Is there any way to start sticking labels onto any of my code to give it a "module name"?

(I've opened a support request but this is a big program, and it's taking a lot of time to get him set up to run it, so he hasn't reproduced the bug yet.)

[rolfk]

Modules in Microsoft speak are usually DLLs, or could be also assemblies in .Net applications.

If the crash interceptor can't determine the module name or at least the process/program name, things would seem to be badly hosed. A crash in some kernel context might be the culprit.

[BertMcMahan]

Interesting. No, I'm not using any custom DLL's. I'm using a lot of TDMS functions, which of course wrap around DLL's, but I didn't modify anything there- just standard stuff. The only bit of info in the Event Viewer is the name of my executable.

The bummer is that I don't even get the "We're sorry, we encountered a problem and need to close" popup. The whole thing just closes, throwing some mostly useless stuff into the Windows Event Viewer.

[mcduff]

It could be a bad TDMS file. I have had the following happen to me...

1. I want to convert TDMS to another format. Some of those TDMS files are written using the DAQmx Logging feature.
2. I would like to write "raw values" instead of doubles in the other file format.
3. I try to change NI_Number_Of_Scales in the original DAQmx TDMS file to 0 to get the RAW values. Note this works for a non DAQmx TDMS file.
4. Upon trying to read the TDMS file after changing the number of scales, LabVIEW immediately crashes.
5. Interestingly if I change NI_Number_Of_Scales in the original DAQmx TDMS file to 1, it is originally 2, I can see the raw data values, that is I16 or I32. However, the TDMS data type stills says 10 for doubles.

You are probably not doing this, but a suspect TDMS file can crash LabVIEW without any message or warning.

[BertMcMahan]

Interesting... I certainly could have a bad TDMS file. I'm not writing them with DAQmx, but they sure contain a boatload of data. Any ideas on how to check if a TDMS file has gone bad on me?