LabVIEW
LabVIEW 8.6.1 crashes
Solved!
Thanks Ben,
Have to go do a recalibration of our signal paths before I can research that, so it will be later in the morning I guess. Mountains of data with the answer would be better than the blinding changing things and then waiting to see if the problem goes away. Of course I'm not certain that the problem doesn't still lie in the .dll, but need a way to determine that so that I can work with its manufacturer. Then again, it might be something entirely different (that has never happened before 😉 ).
Putnam
Yeow! Mountain of data is an vast understatement! Not sure how I would use it to trap, got something like 1M lines of process info after a few minutes, don't think ~12 hours worth will fit on the hard drive! Still trying to pin it down. Any patches for 8.6.1 that might be approriate that I have overlooked?
Flumoxed in the Souther Tier
A new, interesting, symptom was discovered yesterday. I had one crash in the morning, while trying to open a vi while my main vi was running. This time I did get a MemoryManger ... error. Closed LabVIEW and relaunched. As the day progressed I started having multiple," no message other than the "Something has happened to LabVIEW" crashes", which, when clicked, eventually closes LabVIEW's displayed screens. I say displayed screens because at one point I started running
Process Explorer (from the Microsoft site) and discovered that there were 4 instances of LabVIEW.exe running,each at ~180M of memory. Apparently clicking the window message that LabVIEW is going to be shut down, doesn't!
"Curiouser and curiouser cried Alice!"
I am going to remove LabVIEW from this machine and do a fresh reinstall, grasping at straws now.
Reinstalling LabVIEW didn't help. I am now going to try and remove some parts, while still having functionality, and see. My biggest worries are the .NET part (created in house), which is used only at startup, and the DIO call, a dll supplied by the IO card vendor. If not those ...
Ok sports fans, ran program on my laptop rather than the Lab machine and got a crash, but this time was able to find the error log and dump file. Apparently this permissions on the Lab Rat machine are such that I couldn't see the temp directory holding them, but on mine ... Apparently it is a "Read from location 0003001c caused an access violation" that is causing me this grief, but now that I have the .dmp and "NI_Errorlog.txt" what do I do with them. I used to be able to sort out dump files on Windows 3.1 machines, but anything I knew I've forgotten.
Thanks,
I will attach the error log. Not sure about a suggestion (through a different path) of using ProcMon to see if anything is launching LabVIEW, partly because I'm not familiar enough with ProcMon to feel comfortable running it, saw it generating tons of data, not sure how to filter for what I want. As to the observation that there were 4 instances of LabVIEW running, I think that was due to the Windows Dr. Watson error window not actually shutting down the LabVIEW process, despite warning that it was, so that subsequent attempts to run launched a new instance without closing the old. Now having multiple instance running might explain why I was getting more frequent crashes, but I have gotten crashes with the system freshly rebooted, only saw one instance running before crash. None of the .dll/.NET that I'm running "know" about LabVIEW, they are comms to usb interfaces or to web servers on the target system. I also have gotten the crashes now with them actually removed from my code, dummy examples of what they would return to my program substitued in their place, so it does concern me as to what is going on. I am doing "interesting" parsing of clusters to read and write to ".ini" files, etc., using the OpenG varient "stuff", it being more flexible than some similar code I was using before, am using "plugin" vi's that are loaded and run based on a test script's selections, and amusing a tree control loaded from data returned by my .NET call to the system under test. I have used variations on most of these in the past, but never all in the same program. Had thought (hoped) that the .NET or .dll code might be the issue, had seen similar "random" crashes in the past when a .dll didn't behave well, but with them actually removed ...
In a text search neither DWarn or DAbort is present. The attached file is the one that Dr. Watson creates (I think) in "Documents and Settings\'user'\Local Settings\Temp" not the one LabVIEW creates in the ..\LabVIEW Data\lvfailurelog directory, LabVIEW isn't detecting the problem (with the very rare exception of the MemoryManager 437 crash).
Ok, having run my program in a number of stripped down configurations I think that I have narrowed it down to one of my original suspects, not sure why some of my tests a week ago didn't isolate it. It appears that the calls to the .dll that controls a DIO card are where the problem lies. In discussions with the manufacturer they have told me that their dll is essentially a wrapper around a dll from FTDI, the USB folk. So I have downloaded their LabVIEW examples (LabVIEW 7.x!) from their site and am able to do the basic ID'ing, getting a handle, for my card. The board's manufacturer is going to work with me to make the somewhat lower level calls to the FTDI .dll directly. My question, and it is a biggie, has anyone experience with the FTDI ftd2xx.dll ? In their examples the dll calls are marked "Run in the UI thread" rather than "Run in any thread", the later being what we used to call "thread safe". I have had random crash problems in the distant past that were eliminated by making the dll "thread safe", not to mention that running a dll in the UI essentially stops the UI from updating until the dll returns. Thankfully the enter, returns on these dll calls is fast, but they are frequent.
