Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

CPU usage to 100% by winlogon.exe using DAQmx

Hello,
although many posts are present dealing with "100% CPU usage", my problem is slightly different from those already posted.
I am experiencing a strange behaviour programming a PCI-6602 on an Intel P4, 3 GHz mother board with an Intel chipset and WinXP professional SP2, under LabWindows CVI 7.1.1 (3.1.4) using NI-DAQmx 7.4. The application is using all the onboard resources, i.e. all the available counters, but implementing all the suggested programming techniques (i.e. an acquisition loop with a delay inside rather than a timer-based or an as-fast-as-possible loop method, alternating the data transfer mechanism between DMA and interrupts depending on the mother board resources, etc.).
What makes my problem different from the other already posted are the following factors:
1) the CPU usage rises up to 100% randomly. Some application executions cause this behaviour, sometimes not. Starting the acquisition by a UIR toggle sometimes causes the 100% cpu usage, sometimes not.
2) looking at the task manager reports, it appears that it is not my application requesting all the CPU resources, but another process, namely "winlogon.exe". Apparently this process has nothing to do with the application at all. This process, however, requests the 100% CPU only when my application executes, as if it were triggered by the application itself.
Can anybody help me understanding what it is happening ?

Thanks in advance,
sincerely
Marco Sartore

P.S.
Here is a snippet of my data acquisition code:

do {      
        ProcessSystemEvents();
        if (module_A_connected)
        {     
            DAQmxErrChk(DAQmxReadCounterU32 (TaskCtr0MultiSamplesAcquire, -1, 10.0, Ctr0TemporaryBuffer, (uInt32) BUFSIZE, &Ctr0ActualAcquiredSamples, NULL));
       
            if (Ctr0ActualAcquiredSamples > 0)
            {
                // store and plot data
             }
          }
          // repeat for other 3 modules (i.e. counters)
       }
       Delay(loopDelay);     
    }
    while (!acquisition_stopped);
0 Kudos
Message 1 of 3
(7,910 Views)
Hi,
I've never heard of similar problems before with NI drivers, but searching the web for "winlogon.exe" i found a lot of references of people complaining that winlogon memory usage is big and there is a suspected memory leak.
Can you test your software in a different PC? It would be very helpful to check if it is a reproducible behavior or if it could depend on that particular PC o OS. If you want to post your code and the instructions to run it (including external connections if any) I could try it on my system.
Let me know. Ciao.
 
NicolaC
National Instruments

Message Edited by Nick_ on 09-22-2005 11:23 AM

0 Kudos
Message 2 of 3
(7,898 Views)
Many thanks for your answer (and let us continue speaking in English for the benefit of other Users...).
Unfortunately it is useless to post the application software, as it needs specific hardware, not just signal connections at the board output connector.

However my application runs perfectly only (up to now) on the following hardware:
Pentium4 i48 ASRock chipset Intel 848P+ICH5, processor P4 3000 HT (sigh, this is my development machine... I was happy when everything worked well and frustrated when I discovered that it was working only on this PC ! By the way, I tried on another identical PC without the development environment, just to figure out if it was a matter of the CVI stuff. The program works fine also there without CVI around...)

It does not work at least on the following machines:
1) NEC PowerMate VL6 chipset Intel 515 , processor P4 2930 HT
2) FOXCOM chipset SIS 963L, processor Celeron D 2600
3) ASUS P4 533 chipset SIS 645DX, processor P4 1800

All the above systems show the system CPU to 100% when running the application.

Please notice that I have tried forcing the use of either DMA or Interrupts selecting the appropriate Data Transfer Mechanism by means of the relative DAQmx function call, without observing any result. Can it be a matter of chipset ? Or BIOS settings (which ones) ?

Thanks for your help,
Marco
0 Kudos
Message 3 of 3
(7,892 Views)