I have a new Win10 laptop. I've installed lots of software, including a 25-year-old Codewright editor that I've customized up the wazoo, and that I've been installing on all my machines for, well, 25 years. After working for a few days, it suddenly stopped, and reinstalling it didn't fix it. On startup, it puts up a small splash window, and normally opens the main window a half a second later (that took more than 5 seconds 25 years ago). It's not using any CPU, and there's nothing I can do but kill the process.
In the past, I've occasionally got my system into a state where Codewright would hang on loading, due to some other program that hadn't terminated correctly, and it was unfrozen by killing off that other process. So that's reason to believe that Codewright is waiting at some global lock which some other malfunctioning software is holding. So I have two questions:
Does this ring a bell? Is there some known failure mode where a program putting up a splash window then switching to another window can be prevented by something else going on the system?
Is there a way to diagnose this, perhaps by finding out what system call it's hanging inside? I tried dtrace.exe, started Codewright, and then stopped tracing, and it produced a 3GB XML file, which is quite a haystack. There's a way to filter it by PID, but since this is a startup problem, I have no idea what the PID will be. Is there a better tool for doing this, or some more appropriate dtrace feature that I missed?
The comment about using the Task Manager to create a dump file actually led me to notice that there is an Analyze Wait Chain function there that I had never seen before, since I haven't used Task Manager much since I switched from Win7. This gave me exactly the answer I wanted. My editor was waiting for something that was being held by some NVIDIA GeForce Experience module. Since I don't use that, I uninstalled it, and I'm back up and running. Thanks for the tip.
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.
When my Windows 10 app runs, it causes a process called Runtime Broker to execute, which takes up a lot of Memory space.
I know my app isn't "Memory-hungry" and it hardly takes 80 MB of RAM to execute. But from the time it starts, the Memory used by Runtime Broker keeps in increasing until the PC gets stuck.
Upon killing that process, the app is force closed by Windows.
I would have posted my source code here, if only I knew which part of the code is causing this to happen.
What are the possible technical reasons for this problem to happen, and what are the possible fixes in my code to prevent this?
Is there something wrong with my code, or is it some API that I am calling?
You can easily delete RuntimeBroker.exe and any other file. I deleted RuntimeBroker.exe and Livecomm.exe by booting a live Linux Dvd and after loading go and mount the c: drive then simply navigate to the file and delete it. Done!
Runtimebroker seems to hold about 60k per file held via StorageFile objects. It's still a bad problem and the only solution is to not hold on to very many of these.
Microsoft just never does anything about this.
Update: Microsoft seems to have quietly ditched UWP. The replacement has "WinUI" and is probably called the Windows App SDK at the moment. No more runtimebroker.exe.
I have a program which I am working on my Dell Laptop XPS 502X. At work, I usually have another monitor plugged in my DVI port and everything is fine. When I work from home, I only have the laptop screen. When I start the program in VS2010, it is very slow and I notice in the bottom of the screen Loading symbols for ...\NVIDIA Corporation\coprocmanager\detourel.dll... which takes around 10-20 seconds every time. Any idea on why this is happening ?
EDIT:
I thought it was a drivers problem, but now it happens again.
I tried the ideas posted in similar questions
-DeleteAllBreakpoints stuff, didn't work.
-No remote symbols fetch or network path
-Enabled Just My Code
Looks like a hook DLL injected by the graphics drivers... driving me crazy!
EDIT 2:
The problem happens on and off, today everything seems find, yesterday, I even noticed it was slow loading the GROOVEEX.dll while the program was running when I was starting a CFileDialog. So it might not just be something related to the graphics drivers.
It looks like nVidia's use of the Detours library from Microsoft. Hopefully this will help...
http://forums.nvidia.com/index.php?showtopic=212704
and
http://research.microsoft.com/en-us/projects/detours/
Run the msconfig tool that is built into Windows to take a look at some of the things that nVidia launches at startup. You may want to try disabling some of the startup items temporarily, but you'll want to research what each item you disable is before doing so, or you may have to go into safe mode to get back to a good state.
happens to me occasionally:
I start my program in visual studio and due to some bug my program goes into 100% cpu usage and basically freezes windows completely.
Only by utter patience requesting the task manager (takes forever to come up and paint itself) I can kill my process.
Do others encounter this too sometimes? Is there a clever trick to get this process down (other than pulling the plug and possible ruining files on the HD)? It now takes 5-10 minutes to kill it properly if the task manager is not accidentally present and I have to request this first
R
p.s. weird that a 'multitasking os' can still allow processes to eat up so much time that nothing else can be done anymore. My program doesn't even bump up it's thread priorities or anything
Check out Process Lasso
"Process Lasso is a unique new technology that will, amongst other things, improve your PC's responsiveness and stability. Windows, by design, allows programs to monopolize your CPU without restraint -- leading to freezes and hangs. Process Lasso's ProBalance (Process Balance) technology intelligently adjusts the priority of running programs so that badly behaved or overly active processes won't interfere with your ability to use the computer!"
http://www.bitsum.com/prolasso.php
I am not affiliated with Bitsum, just a user of their product, and it helps me solve this type of problems.
For what it's worth, I've never see this on either XP 64 or Vista 64, developing C++ apps in Visual Studio. Perhaps an OS upgrade is in order?
Edit: I use Process Explorer as a replacement Task Manager - it wouldn't surprise me if it did a better job of appearing in good time even when there's a rogue process running. And you can use it to boost its own priority.
I usually hit ctrl-alt-delete start the task manager sort by cpu find the offending process and right click and end the process..
task manager usually has enough priority to do this although it may be slow.
I think a shotgun to the head is the only way to be sure.
I generally don't see anything like this happen strictly as a function of an app that's eating 100% CPU. As part of stability / performance testing, I've gotten apps to cause Windows to get very slow, but this is usually done by writing heavily threaded apps (thus causing the O/S scheduler to thrash), or by writing apps that consume all available system memory or resources (much more impactful to the GUI apps than simply one thread that consumes its full share of processor time during its slices).
You say you get this behavior under Visual Studio? VS has a "Pause" button...
Has anyone had and solved a problem where programs would terminate without any indication of why? I encounter this problem about every 6 months and I can get it to stop by having me (the administrator) log-in then out of the machine. After this things are back to normal for the next 6 months. I've seen this on Windows XP and Windows 2000 machines.
I've looked in the Event Viewer and monitored API calls and I cannot see anything out of the ordinary.
UPDATE: On the Windows 2000 machine, Visual Basic 6 would terminate when loading a project. On the Windows XP machine, IIS stopped working until I logged in then out.
UPDATE: Restarting the machine doesn't work.
Perhaps it's not solved by you logging in, but by the user logging out. It could be a memory leak and logging out closes the process, causing windows to reclaim the memory. I assume programs indicated multiple applications, so it could be a shared dll that's causing the problem. Is there any kind of similarities in the programs? .Net, VB6, Office, and so on, or is it everything on the computer? You may be able to narrow it down to shared libraries.
During the 6 month "no error" time frame, is the system always on and logged in? If that's the case, you may suggest the user periodically reboot, perhaps once a week, in order to reclaim leaked memory, or memory claimed by hanging programs that didn't close properly.
You need to take this issue to the software developer.
The more details you provide the more likely it will be that you will get an answer: explain what exact program was 'terminating'. A termination is usually caused by an internal unhandled error, and not all programs check for them, and log them before quitting. However I think you can install Dr Watson, and it will give you at least a stack trace when a crash happens.