I have a C# app which invokes an unmanaged C++ application via Process.Start()
On some machines, if this C++ app aborts, I'm left with the Just-In-Time error dialog showing
Is there a way from C# to detect that the C++ app has errored and just restart it
(I don't have the source to and therefore can't modify the C++ app)
The JIT debugger dialog is showing because the C++ app crashed in some way. Whilst the dialog is open, the process is still present (but suspended) which means that the Process class wont consider it to have "exited" until the JIT dialogue is dismissed or an attached debugger ends the process.
You could either disable JIT debugging on the machines experiencing the problem (I think that disabling the Machine Debug Manager service may disable JIT debugging), allowing the app to crash and die (and, therefore, report as "exited"), or (and I've no idea how you would go about doing this) see if you can make your host C# app attach itself as a debugger for the C++ app and receive notification of the crash from the C++ app, terminate it, and then act upon the information it has ended.
If the C++ is a console based you can check two things,
The exitcode, commonly 0 means closed normally otherwise is problem (but I Think this depends on the convention used to develop this applications)
Check the standard Error if it is empty, so everything is ok
using(Process p = new Process())
{
p.StartInfo.UseShellExecute = false;
p.StartInfo.RedirectStandardError = true;
p.StartInfo.FileName = "any.exe";
p.Start();
string error = p.StandardError.ReadToEnd();
p.WaitForExit()
if(error.Length == 0 && p.ExitCode == 0)
{
}
}
Related
I have an application that works fine under visual studio.
However, when I run it stand-alone, a certain operation which throws an exception isn't handled. (The exception is expected, but it's correctly handled under VS.)
I added a line to my machine.config to enable JIT debugging, to try and locate the problem, but I then could not recreate the bug (the exception was handled correctly). Deleting the line causes the bug to come back.
How should I start looking for the cause?
The relevant parts (I believe) of my code (edited to remove extraneous detail) are at http://pastebin.com/i2zLCTn5.
Some suggestions that may affect how your code is behaving in the different environment of Visual Studio:
Stop Visual Studio turning off the JIT Optimizer when you run your program under Visual Studio.There's an option called "Suppress JIT optimization on module load"...you want to try changing that to be NOT ticked.
For more details on what the option does see here:
http://msdn.microsoft.com/en-us/library/ms241594.aspx
Turn off the "hosting process" ...http://msdn.microsoft.com/en-us/library/ms185330(v=vs.80).aspx
Run the Program, then "Attach to Process" (it then won't be in a hosting process, and the modules will have been loaded and JIT optimized).
In the Exceptions dialog tick the "Thrown" check box of the Exception that is being eated/handled....so that you can track down who is handling it and why. You will need to install the NET Framework Sourcecode if the Exception is being handled there so that you can see the details.
You could have a try at running it under WinDBG instead (it may behave differently as you then won't be running under a hosting process i.e. .vshost)....make sure you have the extension DLL PSSCOR4 (if using .NET 4) so that you can make sense of things.
So, I discovered - or rather, a friend explained - the cause of this problem:
You cannot catch exceptions across threads when JIT debugging is disabled, even if execution appears to flow correctly.
The exception was being thrown in a Form.Closing event handler:
form.Closing += new delegate
{
switch(form.DialogResult)
{
case DialogResult.OK:
// do stuff;
break;
case DialogResult.Cancel:
throw new AbortOperationException();
}
}
// ...
try
{
mainForm.Invoke(new Function<Form, DialogResult>(form.ShowDialog), mainWindow);
}
catch (AbortOperationException)
{
// handle abort
}
The solution was to refactor slightly to eliminate the throw:
form.Closing += new delegate
{
if (form.DialogResult == DialogResult.OK)
{
// do stuff
}
}
// ...
var result = (DialogResult)mainForm.Invoke(new Function<Form, DialogResult>
if (result == DialogResult.Cancel)
{
// handle abort
}
When i am debugging my program and an error occur, the debug session ends, but the program remains in memory. Using the activity manager of Windows to close it does not work. I need to close Visual Studio in order to kill the process.
Why is this happening?
When during debugging a program error occurs, the program usually does not "end". Instead, the debugger (VS2010) pauses execution, allowing you to inspect the code resulting in the error. Depending on the language used (e.g. C#) and the way you compiled your program, you may even be able to edit the program on the fly, move the execution cursor back a bit and continue the program from there.
If the Debug toolbar is visible (in my case it shows up automatically whenever I'm debugging), you should see a couple of "playback" buttons, allowing you to start/continue, pause, stop your program etc. If you stop your program, it will be gone from the task manager too.
As I mentioned in a comment on your question, you can also use the Debug menu to accomplish these tasks.
I am trying to trace a bug in our handling of com objects. Our program is launched from our activeX control, and there is some com issue when the app is closed again. I would like to attach the visual studio (2008) debugger to our app when it is first launched from the OCX. How can I do that?
Some details:
a) OCX and app written primarily in c/c++ with just a little c++/cli (that play no role in the launching of the app)
b) If I attach to the program while it is running I get an assertion on exit in olelock.cpp
void AFXAPI AfxOleUnlockApp()
{
AFX_MODULE_STATE* pModuleState = AfxGetModuleState();
ASSERT(pModuleState->m_nObjectCount != 0); <--- Triggers this
if (InterlockedDecrement(&pModuleState->m_nObjectCount) == 0)
{
// allow application to shut down when all the objects have
// been released
::AfxOleOnReleaseAllObjects();
}
}
So I would like to attach the debugger to our program when it is first launched from the OCX so I can attempt to track the lifetime of the COM objects. Or perhaps there is another way to trace these objects?
gflags is what you would look into for complex scenarios in general. Specifically this page for debugging an app unconditionally when it is launched.
However, I think this is overkill for what you want. I usually just dump some code in my program that will wait for a debugger to be attached if it was built in DEBUG mode and the F1 key is being pressed when the code starts up. Code like this shouldn't get left in, but it's pretty handy.
#ifdef _DEBUG
if ( ::GetAsyncKeyState( VK_F1 ) )
{
while ( !::IsDebuggerPresent() )
::Sleep( 100 );
::DebugBreak();
}
#endif
I am trying to launch an application via the ShellExecute() API call. This application contains only a main function which does some processing and exits.
Now I have put DebugBreak() in starting of main. When ShellExecute() is called the application is launched successfully but it does not ask for breaking.
How can I debug my application when launched from other application using ShellExecute()?
I am using VC++ .
If DebugBreak() isn't workign for you, try _CrtDbgBreak(). Note that _CrtDbgBreak only works in a debug build.
_CrtDebugBreak definitely works for me to make a launched process break on startup, although I'm pretty sure DebugBreak does also.
Note that both functions will make it look like the process has crashed, since they raise an exception. That is normal and gives you the opportunity to attach a debugger via the crash dialog. (The crash dialog also lets you terminate the process; don't use that, obviously.)
Also note that if you have a catch-all SEH exception handler around your main then the exception raise by DebugBreak & friends will be swallowed up and the app will simply exit without showing the crash dialog or letting you attach to it.
You can't do this with VC++; with WinDbg this is just .childdbg 1 to debug all child processes. With VC++, you can use Image File Execution Options in a pinch - check out http://codereflect.com/2009/09/20/how-to-debug-child-process-using-windbgvisual-studio/ for more info. Really though, if you've got the time to learn WinDbg, it's much better at this.
you can try this, it's ok in xp system.
app.exe is your application name,
-s1...-s3 is command line arguments.
HINSTANCE hRet = ShellExecute(NULL, L"open", L"vsjitdebugger.exe", L" app.exe -s1 a1 -s2 a2 a3 -s3", szExePath, SW_SHOW);
There is now a Microsoft Child Process Debugging Power Tool.
The method I use for things like this is to embed some interactive code, which you can either delete afterwards, comment out or conditionally enable. In a few cases we have this code enabled by querying an environment variable which is set by the tool that launches the main application. This allows me to click a check box, hit launch and have the breakpoint dialog in seconds.
if (MessageBox(NULL,
_T("Attach the debugger now, then choose Yes to hit a breakpoint"),
_T("Attach Debugger"),
MB_YESNO) == IDYES)
__debugbreak();
This gives you the ability to attach the debugger when the dialog box appears and the option to hit a breakpoint or not. My earlier versions didn't give me the option and after a while I realised some of the time I wanted the breakpoint, and some of the time I didn't.
When an application crashes on Windows and a debugger such as Visual Studio is installed the following modal dialog appears:
[Title: Microsoft Windows]
X has stopped working
A problem caused the program to stop
working correctly. Windows will close
the program and notify you if a
solution is available.
[Debug][Close Application]
Is there a way to disable this dialog? That is, have the program just crash and burn silently?
My scenario is that I would like to run several automated tests, some of which will crash due to bugs in the application under test. I don't want these dialogs stalling the automation run.
Searching around I think I've located the solution for disabling this on Windows XP, which is nuking this reg key:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
However, that did not work on Windows Vista.
To force Windows Error Reporting (WER) to take a crash dump and close the app, instead of prompting you to debug the program, you can set these registry entries:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting]
"ForceQueue"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\Consent]
"DefaultConsent"=dword:00000001
After this is set, when your apps crash, you should see *.hdmp and *.mdmp files in:
%ALLUSERSPROFILE%\Microsoft\Windows\WER\
See here:
http://msdn.microsoft.com/en-us/library/bb513638.aspx
regedit
DWORD HKLM or HKCU\Software\Microsoft\Windows\Windows Error Reporting\DontShowUI = "1"
will make WER silently report. Then you can set
DWORD HKLM or HKCU\Software\Microsoft\Windows\Windows Error Reporting\Disabled = "1"
to stop it from talking to MS.
I'm not sure if this refers to exactly the same dialog but here is an alternative approach from Raymond Chen:
DWORD dwMode = SetErrorMode(SEM_NOGPFAULTERRORBOX);
SetErrorMode(dwMode | SEM_NOGPFAULTERRORBOX);
I had to disable this for release automation work on Windows 64-bits for Firefox and I did the following:
gpedit.msc
Computer configuration -> Administrative Templates
Windows Components -> Windows Error Reporting
Set "Prevent display of the user interface for critical errors" to Enabled
It is similar what was accomplished for Customer Experience reporting in:
http://www.blogsdna.com/2137/fix-windows-installer-explorer-update-has-stopped-working-in-windows-7.htm
In my context, I only want to suppress the popup for my unit tests and not for the entire system. I've found that a combination of functions are needed in order to suppress these errors, such as catching unhandled exceptions, suppressing run time checks (such as the validity of the stack pointer) and the error mode flags. This is what I've used with some success:
#include <windows.h>
#include <rtcapi.h>
int exception_handler(LPEXCEPTION_POINTERS p)
{
printf("Exception detected during the unit tests!\n");
exit(1);
}
int runtime_check_handler(int errorType, const char *filename, int linenumber, const char *moduleName, const char *format, ...)
{
printf("Error type %d at %s line %d in %s", errorType, filename, linenumber, moduleName);
exit(1);
}
int main()
{
DWORD dwMode = SetErrorMode(SEM_NOGPFAULTERRORBOX);
SetErrorMode(dwMode | SEM_NOGPFAULTERRORBOX);
SetUnhandledExceptionFilter((LPTOP_LEVEL_EXCEPTION_FILTER)&exception_handler);
_RTC_SetErrorFunc(&runtime_check_handler);
// Run your tests here
return 0;
}
In WPF application
[DllImport("kernel32.dll", SetLastError = true)]
static extern int SetErrorMode(int wMode);
[DllImport("kernel32.dll")]
static extern FilterDelegate SetUnhandledExceptionFilter(FilterDelegate lpTopLevelExceptionFilter);
public delegate bool FilterDelegate(Exception ex);
public static void DisableChashReport()
{
FilterDelegate fd = delegate(Exception ex)
{
return true;
};
SetUnhandledExceptionFilter(fd);
SetErrorMode(SetErrorMode(0) | 0x0002 );
}
You have to implement an unhandled exception filter which simply quits your application, then set that filter function with SetUnhandledExceptionFilter().
If you're using the secure CRT, you also have to provide your own invalid parameter handler and set this with _set_invalid_parameter_handler().
This blog post has some information too:
http://blog.kalmbachnet.de/?postid=75
During test you can run with a 'debugger' like ADPlus attached which can be configured in many useful ways to collect data (minidumps) on errors and yet prevent the modal dialog problems you state above.
If you want to get some useful information when your app crashes in production you can configure Microsoft Error reporting to get something similar to ADPlus data.
This isn't a direct answer to the question since this is a workaround and the question is about how to disable that feature, but in my case, I'm a user on a server with limited permissions and cannot disable the feature using one of the other answers. So, I needed a workaround. This will likely work for at least some others who end up on this question.
I used autohotkey portable and created a macro that once a minute checks to see if the popup box exists, and if it does, clicks the button to close the program. In my case, that's sufficient, and leaves the feature on for other users. It requires that I start the script when I run the at-risk program, but it works for my needs.
The script is as follows:
sleep_duration = 60000 ; how often to check, in milliseconds.
; 60000 is a full minute
Loop
{
IfWinExist, ahk_class #32770 ; use autohotkey's window spy to confirm that
; ahk_class #32770 is it for you. This seemed to be consistent
; across all errors like this on Windows Server 2008
{
ControlClick, Button2, ahk_class #32770 ; sends the click.
; Button2 is the control name and then the following
; is that window name again
}
Sleep, sleep_duration ; wait for the time set above
}
edit: A quick flag. When other things are up, this seems to attempt to activate controls in the foreground window - it's supposed to send it to the program in the background. If I find a fix, I'll edit this answer to reflect it, but for now, be cautious about using this and trying to do other work on a machine at the same time.
After trying everything else on the internet to get rid of just in time debugger, I found a simple way that actually worked and I hope will help someone else.
Go to Control Panel
Go to Administrative Tools
Go to Services
Look down the list for Machine Debug Manager
Right Click on it and click on Properties
Under the General Tab, look for Start Up Type
Click on Disable.
Click on Apply and OK.
I haven't seen the debugger message since, and my computer is running perfectly.
Instead of changing values in the registry you can completly disable the error reporting on Windows Server 2008 R2, Windows Server 2012 and Windows 8 with: serverWerOptin /disable
https://technet.microsoft.com/en-us/library/hh875648(v=ws.11).aspx