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 ;-)
Related
On a virtual machine, I was able to unintentionally reproduce an issue that only shows up once every or twice a year. The software is in a state where as long as the application is alive and running, I can reproduce the issue. The only problem is everything was built in release. So when I debug with Visual Studio and try to look at some values, I get the following message:
Cannot evaluate expression because the code of the current method is optimized.
To my knowledge, the only way to work around this is to build in debug. Unfortunately, this isn't possible because as soon as I close the application and restart it in debug instead of release, I may never get a chance to reproduce this issue again.
Is there any tool or anything I can do to keep the software in its current state, yet be able to retrieve some of the values I'm interested in? Again, this is a release build, so I realize a lot of necessary information to debug is missing. I do have the release pdbs / source code for the assemblies I'm interested in. Unlikely that it matters, but I'm trying to look at a Window object's IsLoaded property among potentially a few other properties.
Maybe you can try Project Properties - Build - Advanced - Debug info = Full?
According to this answer I think this will allow you to attach a debugger. Other answers in the thread have mixed answers on the effects of this option, but it may be worth a try.
I was finally able to solve this by using Snoop, a WPF Spy Utility. It gave me the value of the IsLoaded property I was interested in. Some peers also mentioned using Ants Memory Profiler, but it is pretty expensive and isn't as trivial to use.
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.
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.
My c# windows service is dying due to an unknown error deep down in one of the worker threads that it creates.
Is there any way to find out the exception that causes the service to be terminated?
(Without writing in a dozen try / catch / log the error codes).
Just a simple one-time report on the error that caused the service to shut down.
It is simple, implement an event handler for AppDomain.CurrentDomain.UnhandledException and log the value of e.ExceptionObject.ToString().
I'd say that it might be useful to add the dozen try catch so that the next time something goes wrong, you'll have a log of the error (especially useful if you later find an issue that only occurs sometimes in unclear circumstances so difficult to reproduce while debugging).
However, other than that, you can attach Visual Studio to a running process as shown in this MSDN article. To avoid having to do that I usually add some code to the startup of the service so that if the exe is started with a -c command line parameter, it'll run as a normal process which can be started from Visual Studio. This Code Project article shows something similar to this.
There's a couple of things that you can do. First, check the Windows error logs if you haven't already - I know this is probably obvious, and they can be a bit light on information, but it's always worth a look, because occasionally it will help.
The second approach is just a little bit more involved, and I know you've asked for something really quick and one-time, but to be honest I'm about to recommend the best way to develop Windows services, and once you've done it, you will never go back... and it will save you hours of pain, so I'll give you the advice anyway:
Extract the core of your service to be run independently in a simple console app host. This approach means that you can fully run and debug it in Visual Studio running as a plain old executable, or even on your test server with a remote debugging session attached. For the real "live" windows service, your service code is a thin wrapper around your testable, debuggable service core. This has worked for me time and time again.
Your core service will expose Start() and Stop() methods that can be called by your Windows Service host in production. That's it.
There's a really good OSS project called Topshelf that provides a full-featured and well-tested version of the wrapper I've described and you can read a developer's example of it in use it here.
The easy way is transferring the errors from VS to windows error log and checking there. You have to use some third party tools if you prefer to get error log list as a report instead.
Logger in c#
if you prefer go for a simpler/cheaper one try the above code. Its is very easy and simpler than u thought
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 7 years ago.
Improve this question
I'm running a (mostly) single threaded program (there's a main thread that does everything, the others only read stuff). I can get the application to run fine in VS2008 after a minor change (I changed the text of a form, and tab order of another form), but I can no longer get it to work outside of the debugger. Does anyone know what would cause this?
Clarification: Release mode, launched with debugger (F5) works. Debug mode, lanuched with debugger (F5) works. Debug executable, or release executable launched outside of VS or with Ctrl+F5 fail.
It uses Microsoft's Virtual Earth 3D, and it seems to crash just when the 'ring of hope' (loading ring) is about to complete.
Event log says: ".NET Runtime version 2.0.50727.3053 - Fatal Execution Engine Error (000006427F44AA6E) (80131506)"
Culprit: this line:
this.loader = PlugInLoader.CreateLoader(this.globeControl.Host);
Causes it to fail. However, the form that was working uses the exact same line without an issue. This line is nesseccary for the program to function. I have no idea what it's doing.
Another Lead the error seems to be inside the .NET framework. Application worked on another machine, attempting reinstall. Update: didn't make a difference, although when I repaired VS it kept telling me Visual Studio was crashing even though I wasn't running it.
Error
When I launch the program after a couple minutes I get:
Application has generated an exception that could not be handled.
Proccess ID=0x9CC (2508), Thread ID =0xF0C(3852).
Click OK to terminate the application.
Click CANCEL to debug the application.
The disassembly is bizarre:
0000000077EF2A90 int 3
0000000077EF2A91 int 3
0000000077EF2A92 int 3
0000000077EF2A93 int 3
0000000077EF2A94 int 3
0000000077EF2A95 int 3
0000000077EF2A96 xchg ax,ax
0000000077EF2A9A xchg ax,ax
0000000077EF2A9E xchg ax,ax
0000000077EF2AA0 int 3 <-- Crashes here
0000000077EF2AA1 ret
It repeats that same code block several times (minus on ax exchanging with itself)
Besides my computer, it has worked on every machine I've tested it on, except for a VM on my machine which won't install the .NET framework because setup downloads 0 bytes out of 0 bytes for the framework)...lovely windows.
I've had similar issues where timing conflicts were causing the failure, and my debugging (breakpoints and stepping through the code) forced the code to run in the correct order.
Try take off optimizations from the Release build (in the project settings) and see if that helps.
I fixed it, the .NET 2.0 Framework was corrupt and when I reinstalled it, everything magically started working again.
I cannot tell you what exactly the problem is, but here's what you could do to get a clue what's really happening. I assume you're using VS2008 or 2005.
Switch to release mode
Go to Debug\Exceptions, and mark all "Thrown" exceptions, like illustrated here: http://vvcap.net/db/JbWS_tzy2IpBoI7R7amm.htp
Run executable in debugger, ignore the warnings from VS that there's no debug info
It does seem that there's a win32 exception thrown some time during execution, but this way or another, you will get one or more messages from debugger explaining what kind of exception happened and where. In most cases those messages make it pretty clear what exactly went wrong
EDIT: One thing I forgot to mention is that unmanaged debugging must also be turned on, such like here (when you start program directly from IDE) or here (when you attach to running process)
Here is a support article with that error. Does that apply?
Perhaps the debugger is eating an excaption the VE3D API is throwing. In VS, do a ctrl+alt+e and change it to break whenever any exception is thrown. This can be tedius b/c it will break on all your try catch blocks, but it might give you some information.
Here is some info. about that PlugInLoader. It seems to imply it must be called from the FirstFrameRendered eventhandler. Perhaps one of your forms is doing that and one not?
Search for #if(DEBUG) directives?
Search for Debug.Assert(?
Have you googled the error? I found this thread (admittedly not horribly helpful)
I once had a similar problem with exactly the same behaviour using a plug-in-system. When loading a plug-in from a MarshalByRef-object (see example code below), it seems as if .NET creates a new AppDomain or Context for the loaded assembly. (Can anyone confirm this? I've not found any source regarding this.)
public class ProxyAssemblyLoader : MarshalByRefObject {
public Assembly GetAssembly(string path) {
return Assembly.LoadFrom(path);
}
}
Furthermore in my case the plug-in loads a different version of the mscorlib. (My app is CLR2 and the loaded is CLR4) Afterwards I used the plug-in by reflection and tried to access a value of the new mscorlib, which was loaded from the other application domain. Usually both should be usable because the mscorlib is a commonly used assembly and only loaded once (see Global Assembly Cache). But it seems as if this is not the case. But in general Microsoft advises to avoid that.
I've not exactly figured out what the problem was, but I figured out the call that causes the application to crash without any hint. Why without any hint? It crashed without any hint, because the thrown exception was only available in "the other" appdomain and not available for the main/default app domain.
The taken action was just implicit copying the value of another appdomains assembly to a local untyped value (object) in the default appdomain. This was enough to get a type identity mismatch error due different versions of the assembly. It seems as if Visual Studio could handle it, but if the application runs standalone it crashes.
This may also explains why you needed to reinstall your .NET. Maybe your installed .NET-Framework was a beta or something like that, which contained a minor difference.
In conclusion some general solutions for the problem could be:
Avoid using different versions of assemblies with different versions of the same type.
In other cases may try to load both assemblies inside the same appdomain. (As far as possible regarding the probing context.)
A solution for cross appdomain communication could be serialization of the values.
(Make sure that the correct .NET-Framework Non-Beta Version is installed.)
we found and fixed this issue with MSFT, we faced this problem with VSTO development.
Apply the following patch from MSFT.
http://support.microsoft.com/kb/975954
http://support.microsoft.com/kb/974372
One thing left I think is to use WinDbg to try and debug it. Here are some links on how to use it:
http://www.codeproject.com/KB/debug/windbg_part1.aspx
http://blogs.msdn.com/johan/archive/2007/11/13/getting-started-with-windbg-part-i.aspx
http://blogs.msdn.com/tess/ (good blog about debugging in general in windbg)
Thinking about it, it could also be some service or something that's clashing. Try stopping all unneeded services and closing unneeded programs (including startup ones) and see what happens then.
I had the exact same issue with one of my console applications. I determined that it was my antivirus (Avast) that was causing the issue.
Add the BIN folder to the exclusion list and disable "DeepScreen".
Then rebuild the project and try again!