Windows 2000 "Lock Computer" crashes DAQ drivers in Labview

[billings11]

I have a life test application I wrote some time ago in labview 6.1, which has since been converted to labview 7.1. The system has a PCI-6031E and PCI-6733 running in a windows 2000 computer. I originally wrote all the DAQ stuff using traditional DAQ and I would like to not rewrite it all in DAQmx. The system has to run 24/7 to life test some UUTs.

My problem is that my IT department wants security on the computer so anyone can't just come up and have network access under some other username, so they are asking if I can come up with a way to secure the computer. I have tried "lock computer" in windows 2000 as well as password protected screen savers. In both cases, for some reason once the computer is locked the system goes into a traditional DAQ driver dll call and hangs. It seems like it isn't one particular dll, it is any dll under a traditional DAQ vi. this morning it was the dll buried in AO Clear.vi. Even worse, when it hangs, it REALLY hangs. I can navigate through all the diagrams but I can't abort the vi's. The only way to get out of the labview app is to reset the whole computer. Keep in mind everything runs perfectly until I "lock computer" in the crtl-alt-delete menu or the screen saver kicks in.

Has anyone else had this issue? This is a pain and I need to satisfy some windows secrity while keeping my application for getting all hosed up. Anyone have any suggestions?

[billings11]

Oh come on nobody has ever had this problem? Gimme a little help here!

[billings11]

Its actually pretty funny because my Windows guru IT guy insisted that there was absolutely no possible way locking the computer would cause a crash, and refused to believe the bug was only happening when I locked the computer. I actually had to take him over and show him like three time before he believed me.

[Conseils]

In principle your IT guy is right.......

That is to say that given the millions of applications running under windows 2K and XP, simply calling up the 'Lock Computer' function should not in its self cause a problem.

My all time record for Windows NT 4 was +3000 hours... We had to take it down because there was a critical patch to be applied. Shame really, in the end we used to remotely query the running hours counter - just ticking away.... This was when people said Windows would not run for a day reliably. It became an academic excercise in reliability testing of Windows and the associated hardware / software.

That leaves Labview, well I in common with many people on this forum run Labview for thousands of hours without too many problems....

So where does this leave you????

I would start with the basics....
There are a thousand and one causes for this kind of problem but here are some of the more common ones.

Disk fragmentation
Cross linked files
Dodgy memory
Badly patched system
Lack of system build control (build sequence for software)
Insuficient memory
Dodgy memory
Cheap motherboards and other hardware (even mice or other forgotten peripherals)

I don't think there are going to be many people who see this issue, I think it's most likely to be local to the machine concerned.

Be as methodical as you can be: -
Can you lock the computer before running Labview
Can you load the system memory then lock the computer
Can you lock the computer with Labview running without the application running (I assume its not a 'built application')
Can you lock the computer after just running the I/O config
and so on......

Ohh P.S. I agree with your IT gut... its a real security risk with an unlocked system. The only way round this is to guarantee that your application has control of the machine and prevent any undesired interraction / application. Thus push back and ask him to set the correct policys from the domain!!! That should help keep him busy for a couple of hours. 🙂

Good Luck

Message Edited by Conseils on 05-15-2005 02:40 PM

[billings11]

Thanks for the response. I know he is right about security, and I don't want someone in there using the computer on my username anyway. I still have the problem of not locking my DAQ hardware. The system can and has run hundreds of hours without being reset, and if you take out the whole "lock computer" problem it has been very reliable.

It isn't labview that is crashing, it is something in the DAQ hardware or at least the low-level dll drivers that labview is calling. When it locks I can navigate through my vi's and put them in debug mode. When I do this I can get all the way down to the dll call and in debug mode I see that execution is frozen inside the dll call. Here is something else that's weird: if I "lock computer" labview will execute into whatever DAQ dll call is next and simply never return from the dll call. If I use a screen saver the computer will run for several hours before eventually doing the same thing. If I don't use either it will run fine indefinitely.

Now all other windows programs open and close with no problems. I can open word or explorer and use them, my labview GUI's on independent execution threads from the hardware stuff run fine. But the execution thread containing the dll call that is frozen is totally locked. I can't abort that thread without resetting the computer. Ctrl-Alt-Del doesn't even work, it has to be a hard reset.

After the reset I have had to really mess around in Max to get the cards to start working right again. I have to delete the DAQ cards from max and the windows system and do add new hardware and totally set them up again. That has pretty much been the only way to get the system back up and running again. It's almost like as soon as I "lock computer" the IRQ's for the DAQ cards start conflicting with something and the hardware locks, but that can't be possible!

The thing that has me baffled is that I agree with the IT guy that locking the computer shouldn't cause a problem... and yet it does. The computer is a high end machine, ASUS board, Kingston RAM, Athlon. Nothing cheap. I am sure the disk might be somewhat fragmented, the program is basically logging thousands of files to the hard drive as it runs and aquires data. The problem doesn't seem to have much to do with anything other than locking the computer, though. It is one of those really annoying problems that shouldn't be happening. Anyone else have any ideas about what else I might be able to use for security?

Message Edited by billings11 on 05-16-2005 08:00 AM

Message Edited by billings11 on 05-16-2005 08:03 AM

Message Edited by billings11 on 05-16-2005 08:03 AM

[Conseils]

Can you leave the Nidaq test panel running for a long period of time and lock and unlock the system?

Another thought is timing. Perhaps you could modify some of those interesting BIOS settings that one sees. Even under clocking the CPU for a bit if possible.....

[billings11]

Message Edited by billings11 on 05-16-2005 03:33 PM

[billings11]

Good ideas, I'll try em out.

[Conseils]

I once returned a new board for poor quality soldering. They had just changed manufacturing location to Hungary and boy could you tell... I did make it clear that I was unhappy with the production quality and also described in detail the fault condition.

To my annoyance they returned it - tested, but with the same faulty soldering. There was a dry joint somewhere on the 50 way connector. I never found the fault, I ended up buying a new board.

The moral of the stoy.... make it very clear what you want to happen should you decide to return a board.