My application uses the Win32 SetSuspendState() API to trigger system suspend or hibernation when it has finished doing a lengthy task.
The API accepts a parameter "ForceCritical" which determines whether or not the system suspends immediately or whether it broadcasts PBT_APMQUERYSUSPEND first to allow other apps the chance to cancel the suspend. My app uses this to play nicely with other apps like Media Player, so it doesn't suspend if you're listening to music or something.
For some reason, starting with Vista, MS have changed things so this parameter is ignored so SetSuspendState immediately causes a suspend and other applications have no opportunity to stop it.
Does anyone know how I can get the desired "polite" behaviour back again on Vista?
MSDN says
To prevent the system from transitioning to a low-power state in Windows Vista, an application must call SetThreadExecutionState to inform the system that it is in use
I would guess that WMP does this, but older apps don't. You could probably emulate this by sending the WM_POWERBROADCAST:PBT_APMQUERYSUSPEND message to all top level windows and check their return values (Send the message with a timeout so a hung app does not hang your app)
Related
I want to capture a stacktrace of an application which sometimes stops responding for few minutes.
When the application stops responding, the windows desktop also stops responding to mouse clicks, although some other already running applications are working fine at that time (for example windbg works fine, ProcessExplorer refreshes its screen, but does not respond to mouse events).
While the application is non responsive, it is actually taking about 80% of one CPU core. That is why I would like to get a stacktrace.
The misbehaving application usually takes about 2-3 minutes to do its strange job or if Ctrl+Esc is pressed it becomes responsive immediately (and the start menu opens of course...)
I have WinDbg attached to the misbehaving application and when I issue the Break command, the break-in does not happen until the application starts to respond again.
From what I understand the break-in actually creates a remote thread which pretty soon calls DbgBreakPoint.
What could be preventing debugger's thread from executing?
EDIT:
First of all thanks for your help!
I was also thinking that this might be caused by a bad device driver or something that installs a system wide hook somewhere.
I was thinking to enable kernel debugging and get a stack trace from the kernel for the offending thread or enable manual bluescreen trigger to produce a dump and look at that afterwards.
Process Explorer and Process Monitor does not reveal anything interesting. They also become unusable when the bug is triggered (updating their windows but not responsive to mouse or keyboard).
EDIT2:
Background info:
App uses QT, OpenGL and also DirectSound and runs on Windows 7 SP1 x64
I am currently suspecting something with the graphics part.
The strange thing is that if a system-wide lock is taken (like GDI Lock), this would prevent drawing of other Windows, but that does not happen. WinDbg on same machine works fine. ProcessExplorer updates but does not receive mouse clicks, Desktop updates but no mouse clicks.
I currently have a kernel debugger attached...
EDIT3
ETW was most useful for debugging. It turns out that Qt's main event processing loop goes crazy. PeekMessage and MsgWaitForMultipleObjectsEx (with 0 timeout) gets called in a tight loop. That is where the high CPU usage comes from.
It looks like the App is generating/getting loads of messages at that time. But it is not easy to see what the messages are (or I don't know how to access function parameters in ETW). Using a debugger also does not help much but, with a breakpoint in the QT's event loop leads me to believe that WM_TIMER messages are the culprit.
Given that the desktop also misbehaves during this time, it sounds like your app isn't necessarily misbehaving but merely aggravating a bug elsewhere (e.g., in a device driver or some crummy anti-malware code that has injected itself into other processes). Stack traces from your app may or may not be very revealing.
If the problem is easily reproducible, I'd set a breakpoint somewhere in the "middle" of the app and see if the problem happens before or after that. Then move the breakpoint until you find the last instruction your app executes before things go bonkers. Figuring out what your app does that triggers this behavior may give a clue as what's going on.
Another option is to try using some system-wide debugging tools. First, I'd peak in the Event Viewer to see if there are suspicious error or warning events posting in proximity to the moment the machine goes haywire. Then I'd try a tool like Sysinternal's Process Monitor or Process Explorer to get a better view of what's happening. You might also try ETW to capture a system-wide trace of what's happening on the system that you can study after the fact. (ETW can be hard to use, so check out Bruce Dawson's UIforETW.)
Use ETW to find the cause. Install the Windows Performance Toolkit (part of the Win10 v1511 SDK: https://go.microsoft.com/fwlink/p/?LinkID=698771 which is the last version that works in Win7), run WPRUI.exe, select CPU Usage and click on Start.
After you captured the hang, click on Save. Wait until WPRUI is finished, open the ETL in WPA, setup and load debug symbols in WPA.
Drag & Drop the CPU Usage (Precise) graph to analyse pane and look for WAIT (µs) max for your process to see that long hang and expand the stack to see where it happens.
Platform: Windows 2008 server
Ran into a problem where my one-file exe generated with pyinstaller would not clear its associated temporary folder. Read up about this http://pythonhosted.org/PyInstaller/ and found out if the exe doesn't close gracefully it would not delete its associated temporary folder. After this I spoke to the IT guys who setup the exe and was told that the app is started on system start-up and every night a system reboot occurs.
I tried finding out if the system restart on windows would gracefully exit running applications, but couldn't find anything regarding this.
Does anyone know if windows gracefully exits running apps with a scheduled system restart?
Thanks in advance
Yes, it does, but implementation slightly differs between XP\Vista. You can also change shutdown timer and auto-close behaviour: How to Specify WaitToKillAppTimeout to Speed Up Shut Down Time in Windows.
In Windows XP:
In Windows XP, each running application is sent the WM_QUERYENDSESSION
message at shutdown. Applications can return TRUE to indicate that
they can be closed, or FALSE to indicate that they should not be
closed (e.g., because doing so would cause the user to lose data or
destroy a CD being burned). If an application returns FALSE, in most
cases, shutdown will be cancelled (and the application that cancelled
shutdown is sent WM_ENDSESSION with wParam == FALSE).
Applications can also delay responding to WM_QUERYENDSESSION in order
to display UI asking what the user would like to do. For example, when
Notepad has unsaved data and displays a "Would you like to save your
data?" dialog during shutdown, this is what it is doing. By default,
applications can delay responding to WM_QUERYENDSESSION for up to 5
seconds. After 5 seconds, Windows XP will display a dialog that
indicates that the application is not responding and allows the user
to terminate it. Until the user responds to this dialog, applications
can block WM_QUERYENDSESSION (and, consequently, shutdown)
indefinitely.
In Windows Vista
Ability for users to forcefully shut down
In Windows XP, the UI for
blocking applications allows users to either cancel shutdown or
terminate the blocking application. If subsequent applications also
block shutdown, the system displays identical UI for each blocking
application. This is frustrating for many users, who, when shutting
down, "just want" their computers to turn off. Windows Vista will
solve this by allowing users to terminate the blocking application and
make shutdown "forceful." In a forceful shutdown, Windows will send
applications WM_QUERYENDSESSION with the ENDSESSION_CRITICAL flag. If
an application responds FALSE, Windows will continue shutdown instead
of canceling it, and will send the application WM_ENDSESSION. If an
application times out responding to WM_QUERYENDSESSION or
WM_ENDSESSION, Windows will terminate it.
Silent shutdown cancellations will no longer be allowed
In Windows XP,
applications are allowed to veto WM_QUERYENDSESSION without displaying
any UI indicating why they need to cancel shutdown. These "silent
shutdown failures" are highly frustrating to users, who often take a
minute or two to realize that shutdown has failed because no UI was
displayed. Windows Vista will eliminate this possibility by displaying
UI even if an application vetoes WM_QUERYENDSESSION.
Certain types of applications will no longer be allowed to block
shutdown. At shutdown, Windows Vista will check whether each running
application is not responding (an application is defined as not
responding if it has not responded to any of its window messages in
the last 5 seconds), and, if so, automatically terminate it.
Windows Vista will also not allow console applications or applications
that have no visible top-level windows to block shutdown. In most
cases, such applications are less important to users at shutdown than
applications that do have visible top-level windows. If an application
without a visible top-level window blocks shutdown by vetoing
WM_QUERYENDSESSION, or takes over 5 seconds to respond to
WM_QUERYENDSESSION or WM_ENDSESSION, Windows will automatically
terminate it.
However, if an application with no visible top-level windows uses the
new API to proactively indicate that it needs to block shutdown,
Windows Vista will not automatically terminate it, and will instead
treat it like an application that does have a visible top-level
window.
I need to starting my app when our USB device connected.
My first attempt at this is a background application that pays attention to when USB devices are plugged in. When it notices our device connected, it calls ShellExecute( ) and starts our application.
This works nicely except in Windows 8. Supposing we're on the "Start" screen in Windows 8. In that situation, the application starts in the background and the start screen remains in front.
I think this is a "focus" problem since what I'm actually hoping to do is "steal focus" from the Start screen.
http://blogs.msdn.com/b/oldnewthing/archive/2009/02/20/9435239.aspx
Since my background application doesn't have focus (the Start screen has focus; besides, my application doesn't have a UI), it can't give focus away to my foreground application.
Let me say that in general, I hate focus stealing. Starting the app the user wants to use is a great help to our users.
How can I fix this problem? Maybe the answer is to programmatically ask the start screen to start my app but I don't see a way to do that:
http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/9ed23f32-0708-48a8-9ff7-5fce6dbe123f/windows-8-start-screen-api
Maybe I'm approaching this in the wrong way. Suggestions?
You're going about this the wrong way. Although you can write a program to constantly monitor the USB ports to detect when something is connected, there's no need. The OS is already doing that anyway.
Register an Autoplay handler for your device type and class. This is distinct from the old AutoRun feature, which would automatically execute programs found on an inserted file system.
You can begin with an overview of the feature from the November 2001 issue of MSDN Magazine.
Your handler will be a COM DLL. You can register the DLL as a handler, and register the handler with events you want to handle. You can either perform everything in the DLL, or you can put the bulk of the functionality in your application and just use the DLL as a proxy between the OS and your program.
On Microsoft website I saw this:
What does it mean when a program is not responding?
If a program is not responding, it means the program is interacting more slowly than usual with Windows, typically because a problem has occurred in the program. If the problem is temporary, and if you choose to wait, some programs will start responding again. Depending on the options available, you can also choose to close or restart the program.
On Windows 8, how do you DISABLE "the options" so that users of my application do not see the options to restart my app?
I'd suggest changing your application's design so that this situation doesn't arise. "Not responding" afaik means that the thread with the main message pump is not fetching messages. This is not a good thing to allow to happen.
It's better to do things that will take a long time in a separate thread, and keep responding to the user in the meantime (even if this just means asking them to wait and keeping a dialog responding to mouse events etc).
I want to use a timer in a windows mobile app. Of course, this is not the problem.
The problem: the timer needs to be called even during standby and sleep mode.
Simply switching off the sleep mode is not really an option, since the app needs to comply to windows marketplace for mobiles requirements, and regarding to requirement 5.2 a marketplace app "shall not modify power management options".
Is there a system timer, which could be used to get an event called (like CeSetUserNotificationEx can be used to get an app started)?
Or how would I create a persistent timer?
CeRunAppAtTime can be used to set a named system event (not just to run an app). If the device is in sleep mode when that time arrives, it will wake.