I am trying to repair applications after my no longer working colleague. This application connects with devices by serial port and shows received data in windows form.
It turns out application works almost perfect when I use Release configuration, and throws an exception when it's in Debug.
I used other program to check frame which I send and received. Because in debug exceptions are related with reading this frame. It often throws an exception because frame is too short to read something. I read something that should not get at all, in addition, the second program shows that, despite everything, virtually all frames come correctly.
I don't know possibilities Release and Dubug, and I don't know where I can find something in my project about differences in creating app. Except Configuration Manager which are the same for both.
Can someone tell me why it works in Release and does not in Debug?
App was written in .NET 2.0. Now I changed it to 4.7.2 but it changed nothing in release nor debug.
did you already tried you rebuild your app or try to delete the debug file and restart your program.
Also this is a good explanation I found
When you compile in debug mode, you get ".pdb" files along with your .exe or .dll by default. The pdb files are called "symbols". This is what allows exceptions to give you a stack trace that tells you exactly which class and method failed, and even points to the line number in your .cs file. It also allows a debugger to be attached to your running program and allows you to "step through" your code.
When you compile in release mode, the compiler "optimizes" your compiled code (such that execution is as efficient as possible). To do this, it will compile your code a bit differently from what you actually wrote. In so doing, classes, methods and line numbers will not be as accurate if an exception is thrown. In some cases, the exception won't be traceable at except at a binary level, because something has been compiled into classes or methods that are not contained in any .cs file.
Related
I have a big and complex process that runs on a production environment that's basically a WPF user interface developed in C#. It also hosts threads and DLL's written in C++ unmanaged and managed code.
Typically, if an exception raises, it's caught and the related stack dump is written in a log file for post-mortem debugging purposes. Unfortunately, from time to time, the application crashes without writing any information in the log so we have no clue about who's causing the crash.
Does anybody know how to detect and eventually trace all the causes that make the application crash and are not detected with a simple try-catch block?
To give an example I saw that StackOverflow Exception is not caught and also errors like 0xc0000374 coming from unmanaged code are not detected. This is not a matter of debugging it. I know I can attach a debugger to the system and try to reproduce the problem. But as I told this is a production system and I have to analyze issues coming from the field after the problem occurred.
Unlike C# exceptions, C++ exceptions do not catch hardware exceptions such as access violations or stack overflows since C++ apps run unmanaged and directly on the cpu.
For post-crash analysis I would suggest using something like breakpad. breakpad will create a dump file which will give you very useful information such as a call-stack, running threads and stack/heap memory depending on your configuration.
This way you would not need to witness the crash happening or even try to reproduce it which I know from experience can be very difficult. All you would need is a way to retrieve these crash dumps from your users devices.
You can log exception by subscribing to AppDomain.UnhandledException event. Its args.ExceptionObject argument is of type object and is designed not to be limited by C# exceptions, so you can call ToString method to log it somewhere.
Also check MSDN docs for its limitations. For instance:
Starting with the .NET Framework 4, this event is not raised for exceptions that corrupt the state of the process, such as stack overflows or access violations, unless the event handler is security-critical and has the HandleProcessCorruptedStateExceptionsAttribute attribute.
Solved ! I followed Mohamad Elghawi suggestion and I integrated breakpad. After I struggled a lot in order to make it compiling, linking and working under Visual Studio 2008, I was able to catch critical system exceptions and generate a crash dump. I'm also able to generate a dump on demand, this is useful when the application stuck for some reason and I'm able to identify this issue with an external thread that monitors all the others.
Pay attention ! The visual studio solution isn't included in the git repo and the gyp tool, in contradiction as wrongly mentioned in some threads, it's also not there. You have to download the gyp tool separately and work a bit on the .gyp files inside the breadpad three in order to generate a proper solution. Furthermore some include files and definitions are missing if you want to compile it in Visual Studio 2008 so you have also to manage this.
Thanks guys !
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 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.)
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 built a windows service, targeted for .NET 2.0 in VS 2008. I run it as a console app to debug it.
Console app is working great. I put it on my local computer as a service, compiled in debug mode, still working great. I'm ready to release now, and suddenly, when I set it to release mode, the service compiles and installs, but nothing happens. (No code in service is running at all).
I realize that the release vs debug mode are property configuration settings, but it seems that in release mode, even when I check define DEBUG constant, uncheck Optimize code, and set Debug info to 'full', it is still doing nothing.
Set it back to debug and it's working like a charm again.
(As a sidenote, I tried resetting the target framework to 3.5 to make sure that wasn't the issue, too)
So my questions (in order of importance) are these:
Will using my "debug" version in any way ever cause any problems?
What settings are different between debug and release besides the three I've been trying to change already?
This seems like a weird error to me and has stirred up my curiosity. Any idea what would cause this?
EDIT:
Should mention, I already am using a custom installer. Basically I compile the program (in either debug or release) and then install it with the respective installer.
1) It might, if not directly, so indirectly by making the application slower and making it use more memory.
2) When it runs in debug mode, there are certain things that works differently, for example:
The code is compiled with some extra NOP instructions, so that there is at least one instruction at the beginning of each code line, so that it will be possible to place a break point at any line.
The instructions can be rearranged in release mode, but not in debug mode, so that the code can be single stepped and the result will correspond to the exact order of the source code.
The garbage collector works differently, by letting references survive throughout their entire scope instead of only for the time that they are used, so that variables can be viewed in debug mode without going away before the scope ends.
Exceptions contain more information and takes a lot longer to process when thrown.
All those differences are relatively small, but they are actual differences and they may matter in some cases.
If you see a great difference in performance between debug mode and release mode, it's usually because there is something wrong with the code, like for example if it's throwing and catching a huge amount of exceptions. If there is a race condition in the code, it may only happen in release mode because there is some extra overhead in debug mode that makes the code run slightly slower.
3) As to what the problem with your service is, I don't know, but it doesn't seem to be related to how the code is executed in debug mode or release mode. The code would start in any case, and if it was a problem with the code, it would crash and you would be able to see it in the event log.
I'm not sure I can speak to #1 or #2, but when I've had problems like that, it was because of incorrect threading/concurrency. I'm not sure how large your app is, but that might be a good place to start.