LabVIEW vs. IMAPI CD-Burning COM Service

[CoastalMaineBird]

I have a client, running Win XP on a 2.5GHz P4/256M box.
I am developing a large LabVIEW app for him.
We will eventually move to an EXE, but for now, he has the 7.0 development environment, as do I.
The program has 450+ VIs, and collects over 200 channels of data at 10 Hz from SCXI, digital inputs, three different TCP sources, calculated channels, and a few others.

It works fine on my system (Win2000 - 1.5 GHz P4 / 512 M), test after test.

However, his box has recently developed some bad behaviors.

Complaints of "out of Virtual Memory" after running 2 or 3 (20-minute) tests. But mostly just locking up. The whole machine would just freeze, solid as a rock. No way out except pulling the plug.
The data should have taken up about 19 Megabytes in memory. Watching the memory usage in Task Monitor on my machine, I would see the peak memory usage hit a peak on the 2nd test and stay there, test after test. So no leaks were happening.

After looking at his system event log, I found two suspects. Shortly before each gap (where the lockup happened), I consistently see these two lines (not necessarily together):
The IMAPI CD-Burning COM Service service entered the stopped state.
The time provider NtpClient is configured to acquire time from one or more time sources, however none of the sources are accessible. NtpClient has no source of accurate time.

So he turned off these two services, and presto! - the program works for 20 consecutive tests. He turned on the TIME service, and it's still OK. But when he turned on the CD service, it's back to locking up after 2-3 tests.

So I googled this message and found out that it's a useful thing - without it the CD burner won't work.

So has anyone seen this before? Is there a patch somewhere? (I don't have XP here, so I can't test it).
Any other workarounds?

[Philip_Courtois]

Hi CoastalMaineBird,

I can't find any information about IMAPI or NtpClient in our database. I will need more information on what is happening in the VI at the moment before it locks up. What kind of external I/O is active when the VI locks up?

Has anyone else seen a similar behavior?

[CoastalMaineBird]

I will need more information on what is happening in the VI at the moment before it locks up. What kind of external I/O is active when the VI locks up?

Well, that's hard to say EXACTLY, since they don't watch the thing second by second. So knowing exactly when it locks up is problematic.
There's an RT board doing PID Engine control (although they're not actually controlling the engine at the moment, but it's active).
There's a SCXI chassis with MIO board doing analog in on 150 channels.
There's a TCP link to a gas analyzer.
There's a UDP listener to that same gas analyzer.
There's two OPC links to Honeywell devices.
There's a DIO board controlling some relays (though the relays are not yet wired).
The whole shebang is collecting data at 10 Hz (the RT is collecting at 100 Hz, then transferring to the host at 10 Hz).
In its spare time, it's updating the display for 30-60 channels at 2 Hz, and storing all this data for eventual writing to disk.

Other than that, the CPU is not doing much. The CPU is 2.5 GHz P4, 256M RAM (512M and 1G ram did not help).

[Philip_Courtois]

Hi CoastalMaineBird,

Wow, this is not an easy one...

One thing that I would recommend is to update the possible drivers associated with the IMAPI and NtpClient services.

Next thing would be to split the application into modules (for each I/O) and run these independantly to check for the issue. That way you should be able to pinpoint what causes the issue.

Good luck!

[CoastalMaineBird]

Next thing would be to split the application into modules (for each I/O) and run these independantly to check for the issue.

It's already split into such modules, for my own sanity's sake.

But just testing that is a lot of time they're not willing to spend. If they have to turn off a service that supports a device they don't have, then that's a cheap fix. Sensible, too.

Trouble is, I don't know if it's honestly fixed it, or just postponed the trouble until the app gets bigger.

[CoastalMaineBird]

I just now realized that I did not post this bit of info:
After my first post here, I found out that they don't have a CD Burner on this machine. So killing the service is no big deal.

But I don't know if that's treating the cause or treating the symptoms.

[Philip_Courtois]

Dear CoastalMaineBird,

I've been searching our resources for any information that could help you and your customer to find out what was wrong, but there doesn't seem to be any information available. Therefore, I will recommend you to turn off the IMAPI service for now and then provide us with more information as you get the chance. We might be able to find out what is wrong, if we know what module is causing the lock-up.

I'm sorry for the lack of help!