Anybody else have nipalsm.exe renamed to nipalsm._xe ?

[RichMyers]

I have a test system using PXI chassis and equipment.  The TestStand/LabView program uses DAQmx drivers to communicate to the equipment.

Just the other day, the test program crashed, indicating that "niSwitch Initialize With Topology.vi<ERR> Failure loading driver module.  The driver for the DAQmx switch is not loaded."  Using MAX, I could not talk to any of the PXI cards, switch, dmm, digitizer.

I tried reloading the DAQmx drivers from disk and reloading my PXI chassis configuration file, but still got the same response.  After much agony, I discovered that the "nipalsm.exe" file in the \winnt\system32\ directory had somehow been renamed to "nipalsm._xe".  From what I have since read, nipalsm is needed for "many other NI drivers", and so I am assuming it is needed for DAQmx to function.  After I renamed the nipalsm file and restarted a few ni component services [nipximu, and nidevldu], I was able to talk to the PXI cards and run my test station again.

What I don't understand is how this could possibly have happened.  The test operators left the PC and equipment running over night.  So, late afternoon on Monday the test was running fine.  Tuesday morning, without a reboot or reload of the test sequence, the DAQmx drivers don't work.

My IT group says that the Trend Micro OfficeScan client would not cause this issue.  In fact, the OfficeScan client indicates that no viruses were found during the last scan -- which would have run Monday at noon.  And since the test program ran successfully all Monday afternoon [I have the report files to prove it], I am forced to acquit the virus scan client.

Anybody ever have anything like this happen??

[Now_With_Underscores]

Hey Rich,

Glad you're up and running at this point. 

This is a masked extension used to transmit .exe files through firewalls, virus scanning programs, email clients, backups, etc.  As you figured out by renaming the file, the code is the same; there's just a different extension.  Windows will not execute ._xe, so this is a security feature that some third party program is implementing.  No factory NI software routine exists to change this extension, but it wouldn't be hard to implement in a VI.  Mozy is the only program I know of that uses this for a non-security purpose (to back up an .exe), but I'm sure there are plenty of backup programs that do this.  What other 3rd party file related software do you have installed on this chassis?  Did you find any other instances of ._xe instead of .exe? 

[RichMyers]

Thanks for your input Knights.  Yes, I am up and running, 99.9% anyway.  And so I posted this question mostly as post mortem follow up to see if I can understand and prevent a potentially recurring problem.  I say "99.9%" because I did need to comment out a step in my TestStand sequence that takes my PXI Switch out of scanning mode -- after I was able to communicate with the PXI equipment and I ran the program, this step would give me an error stating that the switch could not be taken out of scanning mode because the switch was not in scanning mode.  And my test sequence is deployed in 5 other locations in the company, so now my local copy has this one small difference from all the others.

I am aware that the "._xe" is used to sneak files past firewalls and also is often used as the extension within cab files when the executables are compressed before installation.  So firewall/virus-scan/PC-Managment software is first in my line up of usual suspects.

Among this list is a PC remote administration client which was created and maintained by the IT group in my company.  [Would that make it "2nd party" software?]  I plan to get with my IT people to see what logs exist to see if we can determine if their RAC my have renamed the file.  Maybe they pushed out a Windows 2000 service pack the night before my test crashed . . .

Even if I discover what renamed the file, I don't think I will be at the root of my problem.  I verified on my Engineering development station that the "nipalsm.exe" file can be renamed without affecting test operation until after the PC is rebooted.  Since my production technician (tells me that he) left the test station running Monday night, even if nipalsm.exe was renamed during the night, the test should have run just fine on Tuesday morning, because they did not reboot the PC until after they ran into some type of problem.  Still, if I can discover how/why the file was renamed, I hope that it will help point toward the root cause.

As I said, after the test failed to run, the technician tried rebooting the PC.  And, when that failed, tried rebooting the equipment and the PC.  And when that failed, called me in, and I rebooted the equipment and the PC.  That is when I saw the "DAQmx driver is not loaded" message.  When I got the call, the technician reported that the message on the screen was complaining about drivers -- but with the fog of war, who really knows if it was the exact same error message, or if the driver message was even the first error message that was displayed on the very first failure to run on Tuesday morning.

In the time period after I rebooted, but before I found the "._xe" extension, I reloaded the DAQmx drivers, imported my PXI ".nce" configuration file, and (re)set my PXI backplane triggers.  Perhaps the "nipalsm.exe" file was renamed as part of the DAQmx reinstall??

Anyway, I was hoping that maybe somebody else may have had a very similar experience -- say a Win2K update that renamed a ".exe" file -- or a re-installation of DAQmx drivers that renamed "nipalsm.exe".  Something that would give me some more clues, because otherwise I think that I'm stumped -- unless my IT group has a log file that proves their RAC pushed out and update and/or renamed the file on Monday night.

At some point, I will need to come in late and get into debug mode on the production test station in order to determine why I needed to comment out the step that takes the switch out of scanning mode.  Maybe that effort will shed some additional light on the issue.  Or maybe I'll discover some PXI chassis configuration element that I forgot to set up.

If you have any further advice, suspicions, or thoughts, I would very much appreciate them.  Just please don't ask me to cut down every tree in the forest with a herring.  🙂

[Now_With_Underscores]

Hey Rich,

I'm assuming that you're able to successfully use the switch as part of your test procedure even though you're getting the scanning mode error?  If this is the case, I'd make sure that we aren't closing out the switch twice in your code. 

If you see this _xe issue again, I'd recommend placing a file structure monitoring program on you system to see when, why and what is changing the extension.