I've an application that requires timers with 1msec precision. Under windows I call timeBeginPeriod(1) at the begin of main() to ensure 1msec resolution (and timeEndPeriod(1) before program exit). I've some threads that perform periodic activities that use WaitableTimer/WaitForSingleObject to sleep for the required time period.
Sometimes the application starts and works fine (sleep times are correct). Other times the application starts and the timer gets fired at a multiple of 15msec (6 msec timers fired at 15 msec, 20 msec timers fired at 30 msec). If I run the TimerResolution application, it reports that the Windows timer resolution is 1msec (0,997 msec), but yet timers are not fired correctly. If I simply restart the computer, timers return working fine.
I've found the problem occurring on Windows 10 1803, 1909 and 2004. I know timer resolution handling was changed since Windows 2004, but I thought that the problem was not present on previous Windows 10 versions.
Any idea where I can look at into Windows when the problem shows up, in order to understand why timers are not properly fired ?
Thanks,
Massimo
Related
Summary
When putting the monitor in sleep mode in Windows 10, Windows seems to execute some tasks that don't get executed with the screen on.
This is interfering with our software, and we need to get rid of it.
Ful story
For a hardware device with a touch screen, I need to be able to turn off the touch screen when it's not in use, for durability reasons. Windows has a message that you can send to turn it off, SC_MONITORPOWER. More specifically:
SendMessage(hwnd, WM_SYSCOMMAND, SC_MONITORPOWER, 2);
This works fine, but when the screen is off, Windows is apparently sometimes performing some tasks that it doesn't do when the screen is on. We are careful to never write anything to the screen in this situation (that causes huge problems when the screen is off, in fact just having a blinking cursor in a DOS box is using up half a core when the screen is off).
Our software requires a callback to be executed every 0.25 ms. We have turned nearly every task, service and several other things in Windows off, and with the screen on, I can run our software for days without ever missing a callback. But with the screen off I get hiccups. The callback already runs at the highest possible priority.
So there is apparently something that we missed when we turned all services and tasks off. There appear to be 2 causes of hiccups:
One happens once every 10-30 hours or so (not sure of the exact time, it seems to vary). But it always happens 5 times, with EXACTLY 5 minutes (at most a few milliseconds off) in between (so in total it happens 5 times in a 25 minute period).
Beside this, we get a single hiccup typically every 4-10 hours, but the time between occurrences doesn't seem to be very constant so there could also be multiple causes.
I'm a bit at a loss here, and running analysis software can easily interfere with our own software, making it harder to detect when these hiccups really occur and when they are caused by running the analysis software.
Interestingly, I have seen this 5-times-every-5-minutes thing also on a completely different system (different hardware, different OS version), when recording audio in Adobe Audition. Audition misses pieces of audio every 5 minutes in this case, and I think it also only happens when the monitor is in sleep mode and you're not logged in remotely.
We have already tried to turn the touch screen off using direct monitor commands like Nircmd does, and it doesn't support those. My guess is that the SC_MONITORPOWER message is triggering more things in Windows, and if we can turn them off, that would fix our problem. Any ideas?
System
Intel i5-8700 with 6 cores, Windows LTSB, no extra software installed except our own.
Never mind, problem solved. It was not an extra task that was being started, it was one of the existing Windows processes that for some reason only causes issues when the display is off. Since killing them is not an option (Windows will just restart them), I've suspended the following processes, and the culprit is one of these (I don't know which one yet):
sihost.exe
igfxEM.exe (I very much suspect this one)
RuntimeBroker.exe
dllhost.exe
taskhostw.exe
explorer.exe
I have to continue testing a bit longer to be absolutely certain, but so far with these tasks all suspended I've not seen a missed callback in the last 38 hours. I don't know yet if there are any drawbacks to suspending all these things, so I'll try to find the cause(s) and suspend only that/those.
I'm a hobbyist programmer and have written a small application using Python3 and Gtk3.
It has two threads in it. One is a simple clock showing current time and updating the GUI every minute. The other is a countdown timer which can be started and stopped (the thread is killed with a flag on pause, and a new thread created on start). Both threads are daemons and neither interacts with the other.
It is working perfectly in linux.
In Windows it freezes / locks up, even when I haven't started the timer (i.e. only the clock thread is active). Windoze complains: "Python.exe is not responding".
My initial question is just whether it is safe to use threads in Windows. Or perhaps it is not a good idea to use GTK3?
Has anyone else experienced something like this?
I installed a Windows Server 2003 virtual machine (KVM, VM specs 1x 3.8GHz and 1.5GB RAM) and I would like it to autostart a .NET framework 3.5 application right after login.
Unfortunately it takes approximately 30 seconds for my application to start up after the desktop is visible. If I start a different application (such as notepad.exe) manually instead it fires up pretty much instantly. Or if I wait 30 seconds and start my application manually it also starts up instantly.
Is there sort of a default delay for autostart applications or is there another factor I probably don't know about? In order to autostart the application I simply put a shortcut into the All Programs / AutoStart directory of my start menu.
Any help would be highly appreciated. Thanks for reading.
Edit 1: The CPU usage of my process stays at 0% for the first 30 seconds
I have seen similar behavior with XP, and it tends to be applications that require network connections. For some reason, it can take a while to set up the LAN connection upon bootup.
Is your application using the NIC? If so, i't probably sitting there, waiting for the network to come up.
Your edit confirms that your process is actually running. So there is no delay for autostart applications: Your application is running. It's just not doing anything for the first 30 seconds.
Debug your application to see why it is not doing anything for 30 seconds.
My psychic powers tell me that your application is communicating with a service that is delay-started. So it has to wait for the service to finish initializing, which takes 30 seconds.
I just read that while Windows Phone 7.5 background tasks can poll for a location, they don't actually poll real-time from the GPS but rather the location API calls return a system-cached position that's only updated once every fifteen minutes.
That limitation of course completely invalidates any attempt at having navigation run in the background as you can get pretty damn far off-track in fifteen minutes, let alone that a background task can only run once every thirty minutes or so!
That said, Nokia's navigation app and reportedly Runtastic's app do continue tracking when in the background (i.e. not just under the lock screen) and both are in the marketplace meaning they have been approved, so does anyone know how they managed to do what the SDK supposedly doesn't support?
For reference, we don't actually need real-time tracking... maybe once a minuted or so, and we don't need that much accuracy... maybe 100 feet or so... but we do need more than we have been given. We just don't know how they're doing it in approved apps.
You'll only be able to retrieve the location when your PeriodicTask executes (Approximately every ~30 minutes, depending on OS scheduling). The location data it fetches from GeoCoordinateWatcher will be from the OS's cache rather than directly from the GPS hardware. If nothing is running the OS will update this with coarse-grained data approximately every 15 minutes. However if an application has executed and retrieved fine-grained GPS hardware data than this will be the data you'll retrieve in your PeriodicTask. You can see examples of this by accessing the GPS in your foreground app and force-scheduling your PeriodicTask with ScheduledActionService.LaunchForTest.
Based on my experience with background tasks, you will not be able to achieve what you want with either Periodic or ResourceIntensive background tasks.
Despite documentation claiming that they run every 30 minutes, my experience is that they run sporadically and unpredictably. Over the last 14 hours, my app's periodic task has run a total of 6 times, and this is pretty consistent every day - it runs about once every two hours. For resource intensive tasks, I find they usually run about twice a night. I guess the OS has to balance all the processes on the phone and all the other apps clamoring to run their background tasks, so sometimes yours doesn't make the cut. Obviously, your mileage may vary based on your phone (lumia 800 in my case) and the apps you have installed.
If you want to write an app that tracks your location once a minute, my advice would be to enable it to run under the lock screen by disabling idle detection and make sure it has a low memory footprint to conserve battery life.
I just moved from WinXP to Win7.
My software needs to have real time response to I/O so it makes a busy-wait in one thread (which has affinity to run on one CPU).
The result is 100% CPU on one of the cores and 0% CPU for others, on Winows XP it worked just fine.
In Windows 7 the system freezes. (The software is a console application, for Windows application it behaves a bit different. only if the main thread make busy-wait without peeking messages it freezes)
Any ideas ?
So you're using a non real-time OS for realtime I/O. Simply put the code isn't working correctly and should do a non busy-wait (change to a sleep-wait) loop and change the thread timer settings to something that is realtime enough.
See this question to setup windows for millisecond precision on a timer callback.
How to trigger a C# function at a certain time with millisecond precision?