I have a windows application that calls an external .dll. After a while, there were fatal errors being brought to my attention that had to do with user marshaling. There was a source online that with that particular error I was to change my target to x86 rather than AnyCPU. I did so, and now whenever I let the app run, it will exit debug mode and crash the application. But if I set a break point immediately after the .dll call, and step over each line until I receive control of the application again, it doesn't crash. Is there anything specific that could be causing this? Has does one debug this issue?
Thanks!
Stepping code solving an issue is often a symptom of timing problems in the original code. If an external resource loads asynchronously, it will not show up on the stack of the current thread in the debugger, but will be able to be called. Stepping over code induces a delay in the flow.
Thank you all for you suggestions! Fortunately, I ended up getting it to work (with minimal understanding as to why it works) but changing the build target to specifically x86 machines rather than "AnyCPU." This was suggested by a website and can no longer find :\ Hope this helps others than run into a similar issue!
I consider the most common cause of this sort of thing to be uninitialized variables. They pick up whatever was in memory and the presence of a debugger can easily change what's in the unused part of the stack--the memory that's going to become local variables when the next routine is called. Check the DLLs code.
Note that your "fix" makes me even more suspect that this is the real answer.
(Then there's also the really crazy case of a problem with the debugger. Long ago I hit a case where the debugger had no problem loading an invalid value into a segment register if you were single stepping.)
Related
The application uses Xamarin.Android, which may be a big problem in itself. The problem is that sometimes it just quits (process is being terminated) and there's nothing in the log that can be associated with it. (although I guess that it's related to running out of memory, but I can't yet prove it — according to DDMS, most of the times all is OK, and if Xamarin.Android uses another pool of memory, then I don't know how to measure it)
I've searched the code base for "Environment.Exit" and, of course, didn't found anything.
What are the options for finding the culprit of such thing?
You could try to use the garbage collector by yourself. Just run
Runtime.getRuntime().gc();
The Runtime instance has also a method to read the free memory space. So you could figure out by yourself whether it's a memory problem.
EDIT:
Oh I read that Xamarin uses the C# language. But I'm quite sure that C# has similar methods.
When you say log, are you referring to an application log, or the device log?
When tracking down these sorts of bugs, I've always found aLogCat invaluable.
I open it, clear all the current logs, then use my application up to the point where it crashes. Then I quickly go back to aLogCat, pause it and scroll up to where the error is - it's usually found in the nearest red/orange blocks.
There's a blog post here about how I found attributes left out by the Xamarin linker using this method.
I'm getting a strange error on a SharpDX program I made.
The program contains one form MainForm, which inherits from SharpDX.Windows.RenderForm (I'm doing Direct3D 9). I have some logic that kills the program by calling MainForm.Close(), and it works perfectly.
However, when I close the form with the X button, or by double clicking the top left corner of the screen, the program ends with code -1073610751 (0xc0020001).
This is a relatively minor annoyance, because it only happens when the program is finishing, so it doesn't really matter if it exits with an error, because it is actually finishing.
However, this error does not happen when I set a breakpoint at the last line of my Main(). If I do so, and then close the window as I explained, the breakpoint gets hit, and resuming ends the program with code 0.
Apart from SharpDX and one pure C DLL I am calling to one-shot process some data, I am not doing mixed code, or any other weird stuff.
I've looked around, but this code appears to be related to string bindings? other people seem to have this problem when doing weird mixed C++/CLI stuff, but I'm not doing anything like that.
Any ideas? at least on how to get more concise information on this error code?
It is a very low-level RPC error. Which is likely to be used in your program, it is the underlying protocol on top of which COM runs. There are plenty of candidates, SharpDX itself uses the COM interop layer to make DirectX calls. And DirectX itself is very likely to make such kind of calls to your video driver.
It is also the kind of error code you'd expect to get triggered if there's a shutdown-order problem. Like using a COM interface after it was already released. Shutting down a program cleanly can be a difficult problem to solve, especially when there are lots of threads. There are in any DirectX app. It is also very easy to ignore such a problem, even if it is known and recorded in somebody's bug database. Because, as you noted, the program otherwise shuts down okay without any nasty exceptions. RPC already prevented it from blowing up, you are seeing the error code it generated.
There's very little you can do yourself about this problem, this is code you did not write and you'll never find the programmer who did. If you see a first-chance exception notification in the Output window then you could enable the unmanaged debugger, use Debug + Exceptions and tick the Thrown checkbox for Win32 exception, enable the Microsoft Symbol server and you'll get a stack trace when the exception is thrown. Beware this will be in the bowels of native code with no source to look at. But it could pin-point the DLL that's causing the problem. Still nothing you can do to fix that DLL. I'd recommend a video driver update, the most common source of trouble. That's about as far as you can take it.
I work for a shop that maintains a fairly new app. The app still has its fair share of bugs, with numerous tickets coming in daily. The error information we're given with those tickets is not as useful as it might be because the application was compiled in Release mode, which I read is smaller and faster (makes sense).
Are there any ramifications to deploying a .NET application to production that was compiled in Debug mode? I would expect it would be a bit slower, but I've read the difference is nominal. This would assure us that when we get errors on tickets we have line number associated with those errors and this, of course, makes debugging much easier.
Any major red flags that would prevent you from doing this? I'm tasked with researching the possibility. So thanks for any feedback.
Deploying your app in DEBUG instead of Release mode will slow down your performance. Of course compromises can be made. I would suggest one of the following:
Look at adding a global error handler to the OnError in your global.asax-
Look at a compromise similar to this one suggest by Scott Hanselman
My experience is that this can work okay if you're thinking about a desktop (winforms/WPF) app, but under no circumstances should you try this with an asp.net app.
You tagged this [vb.net], you cannot ship debug builds or programs that use WithEvents. There's a known and afaik unsolved memory leak for WeakReference instances if there is no debugger attached. They are used to support Edit+Continue.
First thing you can do is ship the .pdb files along with your apps. In the C# IDE use Project + Properties, Build tab, Advanced, change Debug Info to "Full". You'll get line number info in the exception stack trace.
You cannot completely trust the line number, the JIT optimizer will move code around to make it execute faster. And inline short functions like property getters. You can add an yourapp.ini file in the same directory as the executable that disables the JIT optimizer
[.NET Framework Debugging Control]
GenerateTrackingInfo=1
AllowOptimize=0
It all depends on significance of your production environment, business and performance requirement. Nothing is strict.
Deploying Debug builds is a red flag to me though it is not unheard of. Is this a desktop or server app? Any calls to Debug.Assert that fail could be an issue as those can shut down your app and/or cause a debugger to attach (VS.NET is not the only debugger and if I recall .net fx installs a lightweight debugger). While that can be helpful as a dev it certainly can be confusing to a normal person.
One option that works well is rather than debug builds ensure that your error reporting mechanism includes (either displays or logs) the stack trace information from any thrown exceptions. This help pinpoint bugs very nicely wihtout needing pdbs.
If this is a desktop app, you could try it with a few customers, but heed the advice given in other answers. Try someone who is more of a power-user or having a lot of issues may be willing to volunteer.
I'm getting close to desperate.. I am developing a field service application for Windows Mobile 6.1 using C# and quite some p/Invoking. (I think I'm referencing about 50 native functions)
On normal circumstances this goes without any problem, but when i start stressing the GC i'm getting a nasty 0xC0000005 error witch seems uncatchable. In my test i'm rapidly closing and opening a dialog form (the form did make use of native functions, but for testing i commented these out) and after a while the Windows Mobile error reporter comes around to tell me that there was an fatal error in my application.
My code uses a try-catch around the Application.Run(masterForm); and hooks into the CurrentDomain.UnhandledException event, but the application still crashes. Even when i attach the debugger, visual studio just tells me "The remote connection to the device has been lost" when the exception occurs..
Since I didn't succeed to catch the exception in the managed environment, I tried to make sense out of the Error Reporter log file. But this doesn't make any sense, the only consistent this about the error is the application where it occurs in.
The thread where the application occurs in is unknown to me, the module where the error occurs differs from time to time (I've seen my application.exe, WS2.dll, netcfagl3_5.dll and mscoree3_5.dll), even the error code is not always the same. (most of the time it's 0xC0000005, but i've also seen an 0X80000002 error, which is a warning accounting the first byte?)
I tried debugging through bugtrap, but strangely enough this crashes with the same error code (0xC0000005). I tried to open the kdmp file with visual studio, but i can't seem to make any sense out of this because it only shows me disassembler code when i step into the error (unless i have the right .pbb files, which i don't). Same goes for WinDbg.
To make a long story short: I frankly don't have a single clue where to look for this error, and I'm hoping some bright soul on stackoverflow does. I'm happy to provide some code but at this moment I don't know which piece to provide..
Any help is greatly appreciated!
[EDIT May 3rd 2010]
As you can see in my comment to Hans I retested the whole program after I uncommented all P/Invokes, but that did not solve my problem. I tried reproducing the error with as little code as possible and eventually it looks like multi-threaded access is the one giving me all the problems.
In my application I have a usercontrol that functions as a finger / flick scroll list. In this control I use a bitmap for each item in the list as a canvas. Drawing on this canvas is handled by a separate thread and when i disable this thread, the error seems to disappear.. I'll do some more tests on this and will post the results here.
Catching this exception is not an option. It is the worst kind of heart attack a thread can suffer, the CPU has detected a serious problem and cannot continue running code. This is invariably caused by misbehaving unmanaged code, it sounds like you've got plenty of it running in your program. You need to focus on debugging that unmanaged code to get somewhere.
The two most common causes of an AV are
Heap corruption. The unmanaged code has written data to the heap improperly, destroying the structural integrity of the heap. Typically caused by overflowing the boundary of an allocated block of memory. Or using a heap block after it was freed. Very hard to diagnose, the exception will be raised long after the damage was done.
Stack corruption. Most typically caused by overflowing the boundaries of an array that was allocated on the stack. This can overwrite the values of other variables on the stack or destroy the function return address. A bit easier to diagnose, it tends to repeat well and has an immediate effect. One side-effect is that the debugger loses its ability to display the call stack right after the damage was done.
Heap corruption is the likely one and the hard one. This is most typically tackled by debugging the code in the debug build with a debug allocator that watches the integrity of the heap. The <crtdbg.h> header provides one. It's not a guaranteed approach, you can have some really nasty Heisenbugs that only rear their head in the Release build. Very few options available then, other than careful code review. Good luck, you'll need it.
It turns out to be an exception caused by Interlocked.
In my code there is an integer _drawThreadIsRunning which is set to 1 when the draw-thread is running, and set to 0 otherwise. I set this value using Interlocked:
if (Interlocked.Exchange(ref _drawThreadIsRunning, 1) == 0) { /* run thread */ }
When i change this line the whole thing works, so it seems that there is a problem with threadsafety somewhere, but i can't figure it out. (ie. i don't want to waste more time figuring it out)
Thanks for the help guys!
I have a multithreaded .Net C# application, it uses Direct3D 9/10 and XAudio2. (Direct3D is accessed by only one thread, same for XAudio2. Direct3D isn't the problem cause the error is manifest in either DX9 or DX10 mode without any change in its behaviour.)
Sometimes (there are some areas that gives this problem randomly) this application crash in a rather unspectacular way. Even if the application is started through visual studio with debugger it crash without giving ANY kind of exception. (It start by saying "applicationname.svchost.exe is crashed, etc..etc..Do you want to debug?", if I press yes it tells me "you cannot debug an application already closed.)
There is no way to find out what's the cause of the crash? Cause i've run out of ideas, the debugger isn't giving me any information at all. Without an exception I can't even do a stacktrace or a dump. :P (I'm supposing is a synchronization problem (even thought in that area I'm only doing sequential work...), but hey why isn't launching an exception? :|)
In the areas where the problem occurs I'm unloading a reloading a series of classes related to a novel (in a sequential core thread, so I doubt it can be an issue) and starting a new music through XAudio2. (BTW, what are the multithreading consideration about XAudio2? Is it safe to call from multiple thread?)
Thanks for the help.
P.S. There is a software to attach to mine to monitor all the calls and tells me what's the last call before the crash?
You should try using Windbg, analyzing the crash dump should point you to the problem, if your suspicion is right and it is a synchronization problem, the cause of the problem may be hard to spot.
Have you checked Event Logs in your Windows Administration Panel?
All error of any kind are always logged in this section with minimal details.
One time I had an application that was crashing without exceptions and the only help I found was the Event Log Viewer where I discovered that the source of the crash was a StackOverflowException.