I have a program developed by C# and build by .net 4.0.
This program is a windows client which would read the barcode from a barcode reader (via com port) then send the barcode to back-end server via WCF.
The customer have a script in the client OS which would reboot the OS and automatically start up my program every day. The OS is Windows XP Embedded.
Now the problem is, sometimes when the system reboot, my program cannot be started and an error message box will popup to ask whether send this error report to Microsoft.
The most strange thing is, if my colleague copy the program folder and paste as "Copy of ...." in the same folder with the original one the exe under "Copy of ..." one can run without any problem. But the original one still cannot.
What my speculation is maybe the program was writing log and other record files while the system was forced to reboot. And the files get the read/write lock unreleased.
I have uploaded the error screen shots to flickr. Please click here link to visit.
Without knowing what the actual exception is, we can only guess.
You will need to catch the exception that is being thrown in your application.
The best practice is to encapsulate your code in try/catch clauses.
If you are still getting application crashes, then you can attach an event handler to AppDomain.UnhandledException, or Application.UnhandledException and log the exception(s) being received.
Make sure to output the entire exception stack trace, so you can see where it's being thrown from.
Once you've got the exception, if you can't figure out the cause, then ask another question here with that specific detail. eg: "I'm getting an FooException being thrown when I call Bar() after start-up on Windows XP Embedded"
Sometimes after a reboot, some device drivers, or some hardware, will NOT reset itself. The machine has to be power cycled (turned off and back on) or a command needs to be discovered that will force the device driver and/or hardware to reset.
Referring to image IMG_1348 you posted, the error is thrown in your form constructor.
Seems like either code you added or InitializeComponent code is throwing.
Since you are using XPe, you have some options to debug this issue:
Add message box statements around the various constructors to show initialization progress. Guard before and after.
public Form1()
{
MessageBox.Show("Before InitializeComponent");
InitializeComponent();
MessageBox.Show("After InitializeComponent");
//MessageBox.Show("Before Other");
//Other Initialization Code
//MessageBox.Show("After Other");
}
Attempt to use the remote debugger. I am not sure if this works on XPe, but if it does, and since your code is throwing in the constructor, you need to add code to wait until the debugger is connected.
public Form1()
{
while (!System.Diagnostics.Debugger.IsAttached){ System.Threading.Thread.Sleep(0); }
InitializeComponent();
//Other Initialization Code
}
Related
I have an uwp project testing on Win 10 iot core with raspberry pi 3. I do remote debugging on device. After a while the application crashes and only i can see in debug is that error.'The program .. has exited with code -2147483645 (0x80000003).' how can i see more meaningful things about this. The debug is stopping after that.
Edit
The output in vs 2015 no more message showing.Only that error. My project is about ble devices. I am making some read and write operations with using ConcurrentDictionary from different threads. But all of those operations in try catch block. I cannot be sure the problem is about that because noone coming in catch.Also i have following App.cs code
this.UnhandledException += (sender, e) =>
{
e.Handled = true;
System.Diagnostics.Debug.WriteLine(e.Exception);
};
But this code is not hitted too.
I ran into a similar error while wrapping a C++ DLL for a windows Forms application.
The issue was that I returned an unmanaged const char* from the C++ process and declared it as a string in the C# environment (that is supposed to work) but the system didn't recognize it, but didn't catch any error.
It seems to be a built-in C# behavior. I had to go through an IntPtr and Marshal it into a string and the error magically disappeared.
It might have nothing to do with your setting but the symptoms were the same: "Crashing of the application without warning and no exception thrown or caught."
If I were you, and if you're still struggling with this issue, I would look for issues in the DLL wrappings.
According to this Wiki it is a problem with misconfigured system files. The solution is:
1) Start your computer and log on as an administrator.
2) Click the Start button then select All Programs, Accessories, System Tools, and then click System Restore.
3) In the new window, select "Restore my computer to an earlier time" option and then click Next.
4) Select the most recent system restore point from the "On this list, click a restore point" list, and then click Next.
5) Click Next on the confirmation window.
6) Restarts the computer when the restoration is finished.
To capture the messages written in output window in VS 2010 , trying to intercept a message leading to a bug.
the message that i'm trying to intercept :
A first chance exception of type 'System.Runtime.InteropServices.SEHException' occurred in OpenNETCF.Desktop.Communication.dll
Disconnect
after that when i connect the device the app freezes, with no exception.
How i could capture output window messages or redirect them to a string ? can i intercept when i will use this app in production mode ?
I have tried to capture console Messages but i got nothing apart the console.writeline called from the app , so i think that these messages are not console.writeline calls.
If you are debugging the application then to get the debugger to break when a specific exception is first raised (1st chance exception/thrown) you can tick just the specific exception you want, instead of the whole set of exceptions in Runtime.InteropServices.
See the screen shot below:
If your application isn't currently running in a Debugger, then you can get a debugger to attach to the already running process...by using "Attach to Process"...however, that is not normally done in a production environment.
If you want to analyze your application in a production environment i.e. you can't stop your application or run it in a debugger...then the best way to do that is when the exception occurs to get a "dump" created of the process...which you can then analyze offline in either WinDBG or Visual Studio by loading the saved .dmp file.
The best way to set things up is so that a "full dump" file is automatically created when the exception occurs by using DebugDiag.
http://blogs.msdn.com/b/kaushal/archive/2012/05/09/using-debugdiag-to-capture-a-dump-on-first-chance-exception.aspx
It's also possible to manually do a "mini-dump" of your application process by right clicking on the process in Task Manager and doing create Dump File. Doing manually however, means you are a lot slower at capturing the state close to the time of the exception, and also a "mini-dump" is less useful than a full-dump.
There's a good tutorial here on how to diagnose problems in a production environment:
http://channel9.msdn.com/Series/-NET-Debugging-Stater-Kit-for-the-Production-Environment
My WPF app uses Log4Net to record messages to the event viewer. This is working great on most machines. However, there are two machines in my office where there are problems. One is a physical Windows 7 machine with 2 GB of ram, the other is a virtual machine running XP, which also has 2 GB of ram.
The problem is that even though the users are logged in using accounts with administrator rights, the system won't let them create the custom event log that I set up for my application. This is causing my program to die.
I can add error handling on all of the Log calls, but my feeling on this is I shouldn't. The messages are being logged in the catch handler for another error that already occurred. Just what am I going to do with the error information if it can't be logged?
In any event, I tried to create the custom event log on the XP virtual machine yesterday and it still wasn't created. What exactly do I need to do to get the custom event log created on these two machines?
Tony
It turns out that the problem wasn't in the logging code at all. My program uses WPF for the GUI. It's start-up sequence does the minimum amount of work on the UI Thread so it can display the UI as soon as possible.
The rest of the initialization is done on a background thread. I knew that an error was occurring, but I couldn't find the custom error log in the list of logs in the Event Viewer. It turns out that my code didn't find some data in the database that it needs and was trying to report the error. This is a 2 step process which involves first recording the error to the log and then displaying a custom MessageBox dialog. I was getting a XamlParseException when the program was trying to display this dialog.
To make a long story short, the problem that was crashing the program was the XamlParseException. This was thrown because I was calling the custom MessageBox's Show method on the background thread, not on the UI thread. Because I couldn't find the custom event source in the event viewer, I couldn't find the error, so I assumed that the error was a permisions issue.
By the way, I did try to create the event log manually at one point, and yesterday I checked the registry and did find the entry for the custom event source.
There is one other machine here that is having the same problem. I'm sure it's the same exact issue. I'm adding logic to the error handling to make sure that the custom MessageBox is always called on the UI Thread so the program won't bomb like that if the same issue recurs.
We would need to see how you tried creating the event log on the XP machine...
Generally, you need to read this: http://msdn.microsoft.com/en-us/library/49dwckkz(v=vs.80).aspx
Particularly the note discussing when to create your custom event log:
"In general, create the new event source during the installation of your application. This allows time for the operating system to refresh its list of registered event sources and their configuration. If the operating system has not refreshed its list of event sources and you attempt to write an event with the new source, the write operation will fail. If creating the source during installation is not an option, then try to create the source well ahead of the first write operation, perhaps during your application initialization. If you choose this approach, be sure your initialization code is running with administrator rights on the computer. These rights are required for creating new event sources."
Try creating the custom log in advance of the first logging event to use it.
I've already wrote an application that works user base. I was looking for the best way to use for current user logging-out. So I've used Application.Restart();
Soon I found that the code doesn't work properly and Program.Main() doesn't call back again.
I wondered that my Login form Load Method is not going to perform (The Login Form is calling from program class).
So I'll really thankful if you let me know about my bugs and correct solutions.
http://msdn.microsoft.com/en-us/library/system.windows.forms.application.restart.aspx
Comment listed "Bug in VS2010 SP1"
after calling this method, the application no longer run in debug mode, it's not spawned by the IDE and all breakpoints stop functioning.
EDIT:
This is where something like log4net can really be helpful. It's a very simple library to add to your project and would let you write out debug information to a file so, even though the next instance wasn't spawned by the IDE and wont get breakpoints, you could still do some verification that it's hitting what you expect through the use of Debug traces. Just a suggestion...
A new process gets created, and it's not spawned by the IDE.
A breakpoint is not a valid way to test if Main is entered again.
See somewhat related post:
Does Application.Restart() creates new process for application or no?
If you'd like, you could write to a file or some other simple test in Main just to prove to yourself that it is entered.
Microsoft recently released a solution that allows debugging to continue after Application.Restart(), in the form of a Power Tool:
Child Process Debugging Power Tool
Blog Post
Download in VS Gallery
On a Windows 2003 server I have a pure .NET 3.5 C# app (no unmanaged code). It connects to various other remote systems via sockets and acts like a data hub. It runs for 10-15 hours fine with no problem but from time to time it just disappears. If I watch the app using task manager the memory usage remains constant.
In the Main() function I wrap the invocation of the rest of the app in a try .. catch block which it just blows completely past - the catch block which logs the exception to a file is ignored. If I manually raise an exception for testing, the catch block is invoked.
Prior to entering the try .. catch I do :
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException);
The system has Dr. Watson on it, but nothing gets written in the directory DRWTSN32.EXE is pointing to.
How can I catch whatever exception is causing this?
Try using the debugging tools from microsoft. You can download them from here.
Use adplus to capture the crash and then windbg to analyze it.
adplus -crash -pn your.exe -quiet
Lots of great info about debugging on windows on this blog.
If this is a Windows Forms app, then it's likely that the unhandled exception is being caught by the window message pump, which is why you never see it. To deal with this, see my answer here.
If it's a Windows service, then the exception might be appearing on a background thread and not being marshalled back to your main thread. To deal with this, you need to marshal any background thread back to your main thread, and the exception will be re-thrown there so that you can catch it.
If it's a console app, then I'm a bit mystified.
EDIT: Your comment says this is a Windows Forms app. In that case, you're probably not seeing the exception because it's being handled by the built-in Windows Forms exception handler that does the following by default:
Catches an unhandled managed exception when:
no debugger attached, and
exception occurs during window message processing, and
jitDebugging = false in App.Config.
Shows dialog to user and prevents app termination.
You can disable this behaviour by setting jitDebugging = true in App.Config. Then you should be able to see the unhandled exception by registering for the event Application.ThreadException, e.g. in C#:
Application.ThreadException += new Threading.ThreadExceptionHandler(CatchExceptions);
You could also attach WinDBG at startup and enable breakpoints on .NET exceptions. You can then do a !printexception to see what is going on.
There might be trace of the application in the EventLog.
I have had a .Net app disappear without the possibility to catch an Exception. There was an entry in the EventLog every time this happened.
To view the eventlog just type EventVwr on the command prompt, or run box.
If it's a Windows Forms application, you could try Application.ThreadException.