While coding a console app, I'm using an SAP DLL.
I'm getting the following error when trying to add an SAP object:
A debugger is attached to but not configured to debug this unhandled exception. To debug this exception detach the current debugger.
Code:
SAPbobsCOM.GeneralService oGeneralService = oCmpSrv.GetGeneralService("WEPPAGE");
SAPbobsCOM.GeneralData oGeneralData = (SAPbobsCOM.GeneralData)oGeneralService.GetDataInterface(di.GeneralServiceDataInterfaces.gsGeneralData);
oGeneralData.SetProperty("U_WebId", "1");
try
{
oGeneralService.Add(oGeneralData);
}
catch (Exception e)
{
Logger.WriteLog("Error Add object " + e.Message);
}
Although the code is wrapped with try&catch, the IDE crashes.
After many searches and suggestions around the web, which did not helped, I came across this post and applied the suggested solution and enabled native code debugging under the project properties debug tab.
The result of ticking this option was that instead of letting me debug the unknown error, the exception just "disappeared" and the code runs with no interference.
Questions
Why does the exception disappears and not debugged?
Is it possible to have a different workaround for this problem since enabling the native code debugging is slowing down the app by 10x and not a real solution this problem.
Although the code is wrapped with try&catch, the IDE crashes
No, the WER dialog shows that it is your program that crashed, not the IDE. Not your code, OBServerDLL is a SAP component. And given the nature of the crash, using try/catch is not going to be able to catch this exception, it occurs on a worker thread inside the SAP code.
Do keep in mind that the crash reason is very nasty, exception code c0000005 is the equivalent of an AccessViolationException. The usual reason for it is memory corruption. Never catch an exception like that, your program cannot meaningfully continue operating.
Why does the exception disappears and not debugged?
This is certainly not supposed to happen, very unhealthy. AVEs do tend to be rather random, memory corruption does not guarantee a crash. Keep in mind that when it does occur while you are debugging then you still can't find out anything about the reason, you don't have the source code for the OBServerDLL.
enabling the native code debugging is slowing down the app by 10x
That's quite unlikely, unless the native code is throwing exceptions at a very high rate. Something you can easily see in the Output window. What it does do is slow-down the startup of your debug session. The debugger will try to find PDBs for all the native executables, it isn't going to find anything at the Microsoft Symbol Server for SAP code. Simplest way to avoid that delay is using Tools > Options > Debugging > Symbols, untick the "Microsoft Symbols Servers" option.
This question at the SAP support forums would be somewhat comparable. Also the best place to find help with a problem like this. Albeit that it is likely you need support from a SAP escalation engineer, he'll need a small repro project and a minidump of the crashed process.
Related
At some point while developing my C# application, the following started to appear in the VS Output pane whenever I create an OpenFileDialog:
First-chance exception at 0x75A6C42D (KernelBase.dll) in (myapp).exe: 0x000006BA: The RPC server is unavailable.
I've been maintaining this application for years, and definitely never saw this before, so I started rolling back in SVN to determine when it began.
Bafflingly, revisions in which it occurs & doesn't occur seem to be inconsistent; if I go back sufficiently far it never happens, but there's an "area" when I can check a revision, it won't happen, I'll check another revision, it will, then I'll return to the first, and this time it suddenly will. In other words, I can't seem to reliably pinpoint when it started happening.
To illustrate this, here's an excerpt of my tests, indented for clarity. Numbers are revisions. For each test, I "update to revision" and do a full rebuild.
3977: Exception. This is the most-recent revision.
3839: OK. Since it didn't happen, I'll start working my way back up to see when it starts
3843: OK
3852: OK
3890: Exception. So it started between 3852 & 3890.
3852: Exception. Huh?? I JUST tried 3852, and last time it didn't happen!
3778: OK. Going back this far, I've never seen it happen.
3852: Exception. I guess I'll start working my way BACK to see when it stops.
3828: Exception
3810: OK
3828: Exception. Just making sure.
3810: OK. Just making sure again.
3828: OK. What?? 3828 showed the exception last time I tried!
3852: OK. (but previously it showed the exception)
3890: Exception
I'm aware that I can just tell VS not to break on these types of exceptions, and ignore them. But as mentioned, after years of working on this software, I've never seen it once - so I'd like to determine exactly when and why they started, rather than just turning a blind eye.
This has nothing to do with your project. When you use the shell dialogs, like OpenFileDialog, you load Explorer into your process. Which comes with a lot of baggage, you also get all of the shell extensions loaded. The kind that customize Explorer, they work just as well in the dialog.
Misbehaving ones are quite common. Programmers tend to use the quirkier kind. Any mishap in such a shell extension is now visible to you, the debugger tells you about it.
So, nothing actually went wrong, the exception was caught and handled. Explorer implements counter-measures against bad shell extensions destabilizing it and automatically disables them. So you just have a lame-duck shell extension that doesn't work, low odds you'd notice since it probably hasn't worked for a while.
The debugger can tell you which one is bad. Enable unmanaged debugging and tick the Thrown checkboxes in the Debug + Exception dialog. The debugger will now stop when the exception is thrown. You won't see any source code but you can look at the Call Stack debugger window for hints. It displays the name of the DLL that contain the bad code somewhere on the stack, below the Windows DLL functions. The name ought to give you a hint which one is the troublemaker. SysInternals' AutoRuns utility is excellent to disable them.
While logging exceptions to a database or evaluating the event viewer is very helpful. Many times we are often left wondering how to reproduce the error so we can debug it. There are some good practices that you can apply to serialize the calls and then later with some work reproduce the error and ultimately debug and fix. I am wondering what tools and or best practices are out there to efficiently debug errors to fix quickly based on collected exception information. In other words collect information about any given exception and quickly load into a debug session\step thru the code and more efficiently resolve errors.
Here is something I would consider a dream but would be extremely helpful if it existed.
try
{
//Do something that breaks
}
catch (Exception Ex)
{
LogExceptionExecution();
}
Serialize the information collected from LogExceptionExecution();
Now having the information serialized take the information completely and load directly into visual studio. Visual studio would then create a breakpoint at the start of the method and begin a debug session. The debug session would have everything loaded to recreate what caused the exception in the first place. This would allow you to debug and fix the error without spending valuable time on how to recreate the environment and load the code used during the error in order to debug and fix code.
For your case, you should write a Minidump file when exception happens. Minidumps are a mechanism for "post-mortem debugging" - debugging your application after it is "dead". A minidump is a snapshot of the memory of your application, typically taken when it is has encountered a fatal error.
As how to create a minidump in .NET, please read this.
I have C# code that throws ExecutionEngineException only when I debug it. When I just run it from Visual Studio without debugging (press the "Start without debugging") button, this piece of code works OK. But when I debug it from Visual Studio it throws ExecutionEngineException.
Due to this problem I cannot debug my application, as the code I am trying to debug is executed AFTER the problematic piece of code.
Here are some details:
I am using Visual Studio 2012
The main application is a C++/CLI application that calls my C# code
The application runs for some time until it reaches the problematic lines of code in C#
The relevant code is a query against an Entity Framework context.
I am using Entity Framework 5
The DB where my entities are stored is SQL Server LocalDB (the one that comes with VS2012)
Edit
Further investigation shows that the actual problem is an access violation exception that originates in the default constructor of System.Data.DataSet, which also happens if I just write new DataSet().
Edit 2
I created a small application that demonstrates this problem. The source code can be found here.
You are welcome to compile it and try and run the project Application. It should crash in Adder.cs with ExecutionEngineException when creating a new DataSet. Please note that the debugger should be Mixed and not Managed/Native.
Your C++/CLI code is most likely corrupting the garbage collected heap. A very typical way for unmanaged code to misbehave. This doesn't get discovered until later, like when you new an object or the garbage collector runs. So the code that crashes is completely unrelated to the code that caused the corruption and gives you no hint whatsoever where the bug is located.
There is very little joy in debugging this, it typically takes a thorough code review, lots of unit tests on the unmanaged code and days of debugging to find it. The "crashes only in the debug build" scenario is very common as well, it doesn't mean that there is no heap corruption in the release build. You are a bit lucky that it fails like this, heap corruption is way harder to debug when it occurs in the release build. You'll want to invest in a debug allocator to catch the bug in action, like the one you get out of <crtdbg.h>. This problem in general made garbage collectors a favored way to manage memory.
My condolences and good luck with it.
I wrote a console application that uses Socket's *Async set of methods and it crashes time to time. It doesn't show me where it threw the exception like synchronized code, console just shuts down and I have no idea what have I done wrong.
Is there a way to detect exceptions when it comes to asynchronous operations like this without knowing where to put a try/catch block?
All I need is to know what part of the code makes my application crash.
Edit:
The usual thing with the unhandled exceptions is when you are debugging your code using Visual Studio, it pauses the execution and shows you the line of code that caused the exception (or at least the exception message). But in some situations (e.g. interacting with a low level API like IOCP) your program just crashes and debugging ends with no information about its cause.
What I need is a way to see that particular exception:
"What happened or where (in which method) it happened so my program crashed?"
So I don't ask "What have I done wrong?", I ask "How can I find out what have I done wrong?"
Can I make the execution break at the point where the exception is thrown?
Can I see the call stack after crash to identify the method that caused it?
Could you provide any advice to avoid these kind of situations?
Click Debug-menu -> Exceptions. Make sure Common Language Runtime Exceptions are thrown. Sometimes the IDE unchecks this option. I don't know why, but it's annoying.
Enable System.Net logging to see whats happening underneath
I have an application that after a few times if running it crashes. (application not responding).
when I try to attach my code to process I get assembly debugging, with no helpfull stack trace.
I'm unable to reproduce this from running in VS but only as an application. (therefor intellitrace - which I just read about but not very familiar is irrelevant)
Is there any tool I can use to assist understanding the root cause of the crash
Thanks!
Check the event log or any other logs that your app might be writing to.
Find out if you can narrow down the minimal circumstances to repeat the crash/behavior so you can read the source code to trace the minimal scenario.
If the app does crash when running from VS check whether you are ignoring any exceptions. Look at the Debug | Exceptions dialog and have a look at the output view.
Check your code for Debug.Asserts that are removed from the Release build.
The most common way is to use some kind of Logging system.
Log4Net is very popular these days, you should have a look at it.
Furthermore, if you fix this bug but another one arises on your clients machines, you won't ask them to run a debugger for you, but they can provide you the log file ;-)