I'm trying to write a program to test student code against a good implementation. I have a C++ console app that will run one test at a time determined by the command line args and a C# .net forms app that calls the c++ app once for each test. The goal is to be able to detect not just pass/fail for each test, but also "infinite" (>5secs) loop and exceptions (their code dying for whatever reason).
The problem is that not all errors kill the C++ app. If they corrupt the heap the system calls __debugbreak which pops up a window saying Debug Error! HEAP CORRUPTION DETECTED... My C# app is using Process.WaitForExit(5000) to wait, but this error doesn't count as an exit, so I see a timeout.
So my question is, how can I either get the C# app to detect that this is an error OR how can I get the C++ app to die when this error occurs rather than giving a dialog box and asking if I want to debug?
Edit:
Here's the error that pops up: Debug Error
Here's the normal application failed dialog that pops up if I press retry in the previous dialog: Windows Error. The debug option goes away if you turn off the JIT debugger.
You should turn of JIT debugging, this page has instructions for how to turn it on or off.
Edit You can also use the _CrtSetReportMode and _CrtSetReportFile functions inside the C++ program to change the behaviour of the debug asserts (in particular, you can use _CRTDBG_MODE_FILE to write the contents of the message to a file instead of popping up a dialog.
If you're compiling the program as part of your tests, then you can just add your own .cpp file which includes a global class that does the work in it's constructor. Something like this:
// AssertModify.cpp
class AssertModify
{
public:
AssertModify()
{
::_CrtSetReportMode(...);
::_CrtSetReportFile(...);
}
};
AssertModify am;
This'll cause the code to run before main() is entered which should catch all possible cases (unless the student overrides your value themselves, but you can add a check for any calls to _CrtSetReportMode in their submitted code before you compile it)
I think you need to compile the C++ app in "release" mode. You're probably running "debug" builds which include asserts. Those asserts pop up MessageBoxes which is what you're seeing.
Since you want to catch the assertion failures, you can either modify the code when compiling it (as codeka suggests) or run the programs under a debugger. It's not that hard to make a C# app into a debugger using Mike Stall's wrapper, but it isn't exactly the easiest solution.
Related
It looks like a duplicate, but believe I checked other answers, nothing worked.
My application started crashing while closing the application with below error. It was working properly few days back, some recent changes is causing the issue. And one this starts on a machine, even though I replace with previous working DLL, still the issue comes.
Microsoft Visual C++ Runtime Library
Runtime Error!
Program:C:\DigiMic\...
This application has requested the Runtime to terminate it in an unusual way...
This pop-up comes for 1 second with OK button, then automatically closes. The main problem is it happens while shutting down my application.
My Application: It is a WPF, C# application which uses Matlab used business DLL for few functionality. The application works fine while using the Matlab used DLL and its function, only crashes while exiting the WPF.
I tried to Wrap the App.Current.ShutDown with try..catch... but the it never hits catch orfinally block. Then I also tried AppDomain.Current.UnHandledException += new..., it still does not hit the function on exception.
The other problem is, I am not able to see the complete path of the exe that causes this exception.
Question:
Is there a way, I can suppress this error?
Where is this error gets logged in windows?I tried to look into Event Viewer, but nothing is there.
Is there any workaround? Since it's software delivery time for the product. :(
A program I developed in Microsoft Visual Studios 2010 using c# has been generating the following error: https://dl.dropboxusercontent.com/u/19853155/code%20error%2001.jpg
I have kind of isolated the issue down to this segment of code:
if (gui.rawLogLSM.InvokeRequired)
{
gui.rawLogLSM.Invoke(new MethodInvoker(delegate
{
gui.rawLogLSM.AppendText(t.ToString());
gui.rawLogLSM.ScrollToCaret();
}));
}
else
{
gui.rawLogLSM.AppendText(t.ToString());
gui.rawLogLSM.ScrollToCaret();
}
Basically in this segment of code, I am reading raw data from a serial port, and printing it into a text box, byte by byte. (I can't read the whole buffer in at a time, as that invalidates what we're doing for the project).
I am not wholly sure how this error is actually generated or under what conditions. The error has only presented itself when a co-worker is using the application in my absence, and I've been unable to recreate the error.
The error from info from the exception comes up in form of a message box due to me having a try/catch around a larger block of code, within which the above code is apart of.
So my question is mostly, how can I solve this error or what should I be doing to force said error to show itself?
Thanks for the help!
Could it be that the invoke is on a different thread and the exception is thrown when trying to invoke the textbox while another thread has disposed the textbox(on form close maybe?)? If this is because the textbox is disposed on different thread, one solution would be to surround AppendText and ScrollToCaret inside the invoke with try/catch and swallow that specific error.
The error itself is pretty straightforward: your rich text box is being disposed before you access it. Unfortunately, these can be very nasty to track down, especially if you can't reproduce it.
Do a sanity check and make sure that the RTB is indeed created before the Append()'ing code is called, but my gut tells me you'd get constant errors if it wasn't.
To me, the first step is to reliably reproduce it. Use your coworker's machine, have them demonstrate what they were doing when the error popped up, ensure the framework and application versions are the same, etc etc.
Once you can reproduce it, you'll have to find WHERE the object is disposed. You can do it manually by right-clicking a call to the dispose and choosing "show all references". Set breakpoints on each of them, or use some other monitoring scheme (like a log, which can be used to watch programs on non-development machines). Remember that the System.Diagnostics.StackTrace class is useful for seeing what called Dispose.
There are also tools that monitor memory usage and disposal that can help you out.
I'd also recommend turning debug mode on and giving your coworker the debug-enabled executable and the symbol file (pdb) as this may help track the problem.
Other things to check are race conditions, simultaneous/cross-thread access, exceptions in other threads that may be swallowed by the CLR, only to fudge up your code later on, and make sure you end all threads before you close your form. If you don't, weird stuff can happen. At best, your program will continue to hang in memory, invisible to all but task manager. Worse, you can pop up random error dialogs "out of the blue" as something finally fails. In your case, it might be failing immediately.
I've been writing this program for a while now, and I'm finally ready to start testing it. It works 100% on my dev machine, but I wanted to try it on a machine it's never run on. So, I get my program over to a test computer. When I double-click the exe, nothing happened. I opened up task manager, and tried again. I saw the process start, but after about 5 seconds, it disappeared. No errors, no exceptions, no nothing. How would I go about trying to figure out what is going wrong? I'm still fairly new, and I've never had this happen. Thanks for any and all help!
EDIT
Sorry for not mentioning before. This is a winforms application.
EDIT 2
So, turned out what was going on is that I was trying to a dll meant for 64-bit OS into a 32-bit OS. In Windows XP, this threw a BadImageFormatException. However, in Windows 7, as I stated, it threw no exception at all.
This is a pickle, no doubt about it. I've had to debug this type of thing before.
The first bit of useful information is that no exception is being thrown out. This tells me that somewhere in your actual code is the key to solving the problem. You are either trapping an exception and closing silently, or your code is hitting what it considers to be a "normal" exit condition and is closing in what it would consider the normal way.
To figure out where and why it's exiting, I would add debug logging at key points in your application, and attach a listener to the Debug/Trace listener collection that writes out to a file. "Key points" are places where the application is supposed to exit (or the main form of the window is supposed to close), and within any "catch" block or error event handler. Run this new version on the test computer and see what it gives you. That should tell you the basic flow of the program behind the scenes, and through what mechanism it's shutting down.
If you're running a console application, it is possible that it runs and then closes itself.
Trying opening a command prompt, and then executing the application from there.
If your program has output, then you would see it in that command window.
Have you checked the application event log?
Do you have the necessary version(s) of .Net installed?
Perhaps you should put more exception handling with calls to MessageBox.Show("I failed here") through out your application.
Hi I have been working on a c# application which invokes a dll function. the dll is c code which actually initializes sockets to read/write/manipulate data. dll is compiled with debug info. The problem is under some conditions the c# application pops up a message a saying MemoryAccessViolation in the dll, but does not show any more information. i am basically a linux developer, so i want to know any mechanism to debug such an issues.
Within Visual Studio in the project properties, you can enable debugging of unmanaged code by clicking on the Debug tab and choose that option (Enable unmanaged code debugging). In addition, you can tell the debugger to stop when an exception occurs in you unmanaged code by pressing <ctrl><alt>e (or choosing that option under the Debug menu) to bring up the exceptions dialog.
In the Debug tab, set up unmanaged debugging.
If that doesn't help, it's probably quickest to debug it with WinDbg which should halt execution right on the memory access violation.
Problem is that the violation might be the result of an action that happened far earlier.
There might be better answers but the general route I'd take would be to:
Try and get it to cause the exception on demand. In other words determine what exact conditions cause the error. This might take some time.
Try and capture the exception at the point it happens in the C# code. If your lucky then this may at least lead you to the steps needed for repeating the problem in #1.
If I have access to change the dll written in c; add lots of logging. Hopefully you at least have an idea of where this is coming from.
Here is a forum post with some tips:
http://social.msdn.microsoft.com/Forums/en/netfxcompact/thread/69e84750-6636-4656-bbd4-8d3586290af3
Launch your managed code as usual using VS debugger. Now you would need to launch second copy of VS and attach it to the process you're debugging. Select native code for this second debugger instance. Now assuming DLL is already loaded (anything from that DLL already executed) you should be able to set a break point.
Sometimes it helps to show message box in the native DLL so execution would stop at the point you're interested in and you can attach native debugger and continue.
There is a program where I work that works fine when running the .exe file but works differently from expected when opened in VS2005 and played from there. I am therefore asking on here if anyone knows of anything that would work in the .exe file but not the debug from VS? I am not able to post the code for the buttons I'm talking about but I'll try to explain the best I can.
There is a receiver hooked up to the computer. When the button is pressed on the program, it shows a message and waits for a signal to be received. After the signal is heard the first message box is supposed to close and another is supposed to open. When using the .exe file this happens just fine. However when playing from the program from VS2005 (the same one from which the .exe was made) the second message doesn't come up when it is supposed to and when I can make it come up, the first box doesn't close. There is also a timer involved if that helps.
Also, is there a fundamental difference between how the two operate when executing the program?
If I need to make anything more clear or give more details please let me know.
Running a program under the supervision of a debugger can change the timing of events compared to running the program standalone. The debugger slows things down. Normally, this doesn't make any difference to the operation of the program, but if you have code that is dependent on the "coincidental" rapid timing of some activity, that happy coincidence may be broken when things slow down under debugger control.
The debugger can also cause changes in focus and activation depending on where you set your breakpoints - generally not a good idea to set a breakpoint in focus change or activation events because stopping at the breakpoint will change focus to the debugger, away from your app. But these are interaction issues. Just running your program under the debugger with no breakpoints shouldn't affect focus or activation in your app.
Review your code carefully. Consider what could happen to your program flow if you inserted delays between every source code statement. If that could lead to problems, you have a design bug that needs to be fixed. Reliance on coincidental timings will lead to bug reports and support calls, particularly if your customers have slower hardware than your development machine.
When you run under the debugger, or even in the VS testing host, there are some subtle differences. This shouldn't effect your program under normal circumstances, however, since most of the differences are similar to running (the debug version) of your application on a slower system.
Given your descriptions, I suspect that your problem is actually due to calling to the UI from a different thread than the control was constructed with. Make sure to always marshal any calls to the UI using Control.Invoke or Control.BeginInvoke.
It may be an issue with the Host Process, disabling it is a painless click and just as easy to re-enable. It may be worth giving a try.
Disable Host Process
I know this can effect Direct X and other API but I've never had exactly the situation you are in so I make no promise.