I'm working on a program ("A") which uses ShellExecuteEx to call another program ("B") that occasionally crashes. Program A can detect crash of B, and can kill B using TerminateProcess.
However, when B crashes (and before A has terminated it), up pops Windows' "Program B has stopped working" dialog (WerFault.exe). So although A can kill B, that leaves behind an instance of WerFault.exe each time B fails.
I thought I might have some joy by using the WER api to invoke WerAddExcludedApplication and put B on the excluded list. However, all that seems to do is to change the "has stopped working" dialog so that it offers only "Close" and "Debug", and omits "Check online for a solution".
Any idea how I can get B to just crash without invoking WerFault.exe? (Windows 7).
I did see this thread: How to crash a process on Windows-7 without getting the WER dialog? . However there the intent was to ensure that WER was always invoked, not how to disable or dismiss it.
Suggestions?
Related
In Qt Creator, run a dummy QML app as simple as the following:
import QtQuick 2.0
Item {
}
Go to Application Output pane. Press the Stop button (a tiny red square). An error message will appear. Following is the log:
Starting <path>/qtbase/bin/qmlscene...
**The program has unexpectedly finished.**
<path>/qtbase/bin/qmlscene crashed
This is a bit confusing or misleading, as no crash has been observed. By contrast, this does not happen when the qmlscene window is closed by clicking the Close (X) button, nor does it happen when running qmlscene using the command line on a terminal.
I'm using Qt 5.5.0 on Linux Ubuntu. But this appears to happen also with other versions of Qt.
Was this designed that way, or could this be improved? Thanks!
I have dived into Qt Creator source code. When Stop button is clicked, function ApplicationLauncher::stop() is called. This function tries to kill or terminate process qmlscene, leading to the above-mentioned messages.
So actually Stop means "Kill" or "Terminate" the process.
It would help if the label could be renamed accordingly.
On Microsoft Windows (8), I would like to start a process, and prevent it from showing any windows at all. Alternatively, to force-close any windows that are shown. Is there a way to do this?
My application is this: I'm running an automated (nunit) test suite on my continuous integration (teamcity) server. The code under test is also used by an interactive application. Developers occasionally slip in a dialog with a user prompt, without realising what they are doing. This causes the CI process to stop, waiting for user input which never comes. I'd like to be able to dismiss any dialog that appears, or prevent them from being shown.
Even better would be to force an exception at this point, so that the test would also fail.
In my case, this is a C# application, and the dialogs shown are Windows Forms or WPF dialogs.
I did find a couple of similar questions. However each turned out to be solving a slightly different problem.
Stop a process from showing a window from C# (solves a different problem)
Preventing blocking dialogs/message boxes/hanging GUI from non-interactive processes on Windows? (promising solution but C++-specific)
Prevent child process from creating visible windows? (solves a different problem)
Have you considered asking your development team to have a "no dialog" mode of the app for testing purposes? Perhaps if you stopped referring to them as (!!*&%) they would be more inclined to partner with you. ;) Afterall, you do work at the same company on the same product :)
In any case, without a dev-specific solution, consider having a another app (process or thread) that continually sleeps for a few seconds, wakes up and looks for a modal dialog in your application. You can use APIs such as FindWindow to identify when a modal dialog has popped up. (Use Spy++ to get the class name for windows created by MessageBox and CreateDialog APIs).
I'm trying to debug a VS 2008 command-line application running under Windows XP. The application has been crashing (access violation), and I am catching the crsah in the debuuger. After looking at the call stack, etc., I tell the IDE to "Stop Debugging". The application window remains, but the process does not appear in Task Manager. Nothing happens when I click the "X" in the upper-right corner, though I can minimze / restore the window. The process is normally shut down by pressing Esc. It does not respond to this keypress.
I cannot even get rid of the application window by attempting to reboot XP. The machine will not reboot; it simply ignores my command to do so.
The only way I've been able to get rid of the application window is to do a hard power cycle. Ughh...
Does anybody have any suggestions on how to clean up this lingering application window after the application crashes?
Thanks,
Dave
TL;DR - How does the Spy++ tool really construct its process list?
Stage
We have an MFC desktop application (running on Windows XP) that is hanging in that it doesn't react to any user input anymore. It is redrawn when switching to it via alt-tab however. (It does receive WM_SETFOCUS, WM_ACTIVATE, etc. It apparently does not receive any mouse or keyboard messages.)
Since the app is hanging in some limbo, we pulled a few process dumps, but these were of little help so far. Enter:
Spy++
We used Spy++ to find the information I gave above about the window messages this application seems to be processing. We did this by Opening the Windows View and selecting our application Window and in the Messages properties selected Windows of same process and Messages to View : Select All.
However we first tried to view all messages of this process by opening the Processes View of Spy++ and our application is not shown in this process list. Cross checking on another PC where the app is running normally, the process is also normally shown in the processes list of Spy++.
Can anything about the misbehaving app be inferred from the fact that the process is not shown in Spy++'s Process View, but the main window of the app is shown in the Windows View. Why would a process with a main window that is visible not be shown in Spy++'s Processes View?
The process is listed in Task Manager and in the Attach Process Window of Visual Studio 2005. So these tools apparently use a different method to list processes than Spy++ ... ?
The system where the app is currently hanging is a Windows XP SP2 system and we've used the Spy++ Utility that comes with Visual Studio 2005.
The behavior does recur occasionally, but only after the App has been running for several days!
Running Vista or later? Your process is probably elevated and Spy++ is not. Newer versions of Spy++ require elevation. So, try elevating Spy++ explicitly and see if that helps.
Yes, of course things can be inferred from this. Don't take anything I say too seriously in this context, I'd have to go look at the code. But I believe that Spy goes off and looks at the EnumProcesses API. (http://msdn.microsoft.com/en-us/library/ms682629.aspx)
So, if your process isn't showing up there... hrm.
But, what is different between the system where it's working and the one where it's not?
Spy++ requires the following two values in the registry to be disabled (0) to display the processes/threads list AT ALL:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib
HKLM\System\CurrentControlSet\Services\PerfProc\Performance
Disable Performance Counters -> either 0 or not present
Was going insane trying to find out why it refused to display them. It's some kind of bad joke - this debugger requires itself a debugger to get it working! Not that WinDBG would display any meaningful info, MS doesn't even provide a symbol file on their symbol server, pfft.
Anyway, maybe it doesn't display processes that have their performance counters disabled, because I think, this can be set on individual basis, at least for services, like:
HKLM\SYSTEM\CurrentControlSet\Services\.NET CLR Networking\Performance
Disable Performance Counters
So it's basically always a value of the "Performance" subkey. All this stuff is undocumented, it makes use of advapi32.dll functions like "PerfRegQueryValue" and "PerfRegQueryInfoKey"... don't ask me.
I have a win32 program, when run manually, it display a message in WinMain, but when I put the same program under registry (Run) so that when the PC reboots, it will run automatically, the message will never appear (but the program run normally).
Anyone knows why there is a difference between starting the program manually (by clicking the exe file) and automatically (via Windows Registry)?
Thanks
Clement
It's probably too soon to display a message at the top of WinMain because you don't have a window yet. Can you wait until you receive your first WM_CREATE message?