The following code is causing an intermittent crash on a Vista machine.
using (SoundPlayer myPlayer = new SoundPlayer(Properties.Resources.BEEPPURE))
myPlayer.Play();
I highly suspect it is this code because the program crashes mid-beep or just before the beep is played every time. I have top-level traps for all ThreadExceptions, UnhandledExceptions in my app domain, and a try-catch around Application.Run, none of which trap this crash.
Any ideas?
EDIT:
The Event Viewer has the following information:
Faulting application [xyz].exe, version 4.0.0.0, time stamp
0x48ce5a74, faulting module msvcrt.dll, version 7.0.6001.18000, time
stamp 0x4791a727, exception code 0xc0000005, fault offset 0x00009b30,
process id 0x%9, application start time 0x%10.
Interestingly, the HRESULT 0xc0000005 has the message:
"Reading or writing to an inaccessible memory location."
(STATUS_ACCESS_VIOLATION)
Actually, the above code (that is, new SoundPlayer(BEEPPURE)).Play(); was crashing for me.
This article explains why, and provides an alternative to SoundPlayer that works flawlessly:
http://www.codeproject.com/KB/audio-video/soundplayerbug.aspx?msg=2862832#xx2862832xx
You can use WinDBG and trap all first-chance exceptions. I'm sure you'll see something interesting. If so, you can use SOS to clean up the stack and post it here to help us along.
Or you can use Visual Studio by enabling the trap of all exceptions. Go to "Debug" and then "Exceptions" and make sure you trap everything. Do this along with switching the debugger to mixed-mode (managed and unmanaged).
Once you have the stack trace, we can determine the answer.
A process doesn't exit on Windows without an exception. It's in there. Also, you might want to check the machine's Event Log to see if anything has shown up.
The event viewer shows HRESULT 0xc0000005 "Reading or writing to an inaccessible memory location." (STATUS_ACCESS_VIOLATION)
See my edit above for more details; reproing this takes a while so I can't get a fresh crash dump for WinDBG for a little while.
The solution is to use Microsoft.VisualBasic.Devices, which does not suffer from this bug. Since it's Vista only, and the Event Viewer even managed to fail midway through logging the crash (process id 0x**%9** should have a hex value there instead), I point the blame at the new sound code in Vista.
BTW, connecting the VS debugger to the crashing process remotely managed to first hang Visual Studio, then cause a BSOD on my machine while killing the non-responsive devenv.exe. Wonderful!
Pure speculation here, but the problem may be the using statement. Your code is like this (I think):
using (SoundPlayer myPlayer = new SoundPlayer(BEEPPURE))
{
myPlayer.Play();
}
The using block will call Dispose() on myPlayer, sometimes before it is done playing the sound (but rarely, because the sound is so short - with a longer sound, I'll bet you can reproduce the error every time). The error would be the result of the Windows API (which SoundPlayer wraps) trying to play a buffer which has already been disposed by .NET.
I think if you do this:
SoundPlayer myPlayer = new SoundPlayer(BEEPPURE);
myPlayer.Play();
or even
(new SoundPlayer(BEEPPURE)).Play();
you will not see the error any more.
Related
From a lot of our customers, we have been getting complaints that Outlook unexpectedly crashes (complete process restart) when using our plugin.
So far it has been impossible to reproduce, we can only analyze the logs after the fact and the only thing we know so far is that if we turn one specific add-in off, then the problem stops (it's a local add-in that helps sending e-mails with a configurable template). This add-in runs on .NET and is written in C#.
We have spent weeks gathering and analyzing logs. The crash always reports an Event ID 1000 in the Event Log, which points the faulting module to kernelbase.dll / olmapi32.dll / wwlib.dll / ntll.dll.... or some other dll file. The crash happens on several Outlook builds, old or new, monthly channel or semi channel, doesn't matter.
From our code we were finally able to simulate one crash after running an analysis in VisualStudio which warned us about some potential NullExceptions, when testing with that we could simulate one Outlook crash pointing to Kernelbase.dll. We now fixed this in a new patch and still awaiting results from customers, but in the meantime are there any more options to debug such a random crash? Hope anyone can help us here.
That is a widely spread problem when dealing with Office COM add-ins. The problem can be related to other add-ins, not only yours. Even to locate the source of the issue is very complicated in such cases. You can generate a dump crash and then analyze it to identify the source, but it may not help well because changes made by any add-in may not be detected following that way - the exception which could lead to the crash can be thrown by Outlook itself. For example, a badly written COM add-in may release a COM object and then finish its works, then at some point the host application detects that a required COM object is disposed and cannot continue execution, so it crashes suddenly.
To identify the source of the issue, first of all, you need to add any logging mechanisms to the add-in and see where and when the issue takes place. Then you can try to start simplifying the source code of your add-in by commenting line by line and seeing results after whether it helps or not. It also makes sense to try a newly created add-in, so it can be sure the issue comes from any other add-in, not your own code. There are a lot of helpful steps that could be made, but they depend on the specific scenario you deal with.
You can enable Outlook logs as well. Read more about that in the How to enable global and advanced logging for Microsoft Outlook article.
Try to collect a crash dump using ProcDump.exe and then open it in windbg.
Download ProcDump from
https://docs.microsoft.com/en-us/sysinternals/downloads/procdump
and run the following from command line:
procdump.exe -e -ma -o -w outlook.exe
I built a UWP application which logs data from an internal class to a .csv file using the CSVHelper library. I am having a problem where the application stops responding when running in debug mode without any exceptions being thrown. The app also does not crash. In VS the diagnostic session timer is stopped but the code is still "running". There is no stack trace when I break, the application won't hit any breakpoints and closing the app with the "X" closes the window visually but it doesn't end the debugging session and I suspect the process remains running. I have to use the "Stop Debugging" button in visual studios to end the session. It occurs at seemingly random intervals unrelated to what the app is currently doing. The crashes are usually in the 50min+ execution time range though it has happened earlier.
How do I go about troubleshooting this issue?
I really don't know where to start without any exceptions or even a clue as to what causes the application to hit this state. I would include code but other than just linking the entire repo I am not sure which sections would actually be helpful as I don't know, nor can I seem to find a way to identify what code is running to enter this state.
Problem solved alert. Read the final update first.
.................................................
I have vb6 application that calls a c# library via COM
The C# library is Framework 4.5.2
If I build the COM library on a particular machine running VS2017 15.5.6 I don't have a problem.
If I checkout the same code and build it on a different machine ( I tried 2 of them) with vS2017 15.5.2 in a particular record I get an application crash.
The error occurs on the line of code
if (edge.Extra == null) // given edge is not null and Extra is a property
In the Windows Event log there is
Faulting application name: jtJobTalk.exe, version: 1.0.0.0, time stamp: 0x5a9f5b1c
Faulting module name: ntdll.dll, version: 6.3.9600.18895, time stamp: 0x5a4b127e
Exception code: 0xc00000fd
Fault offset: 0x0006d46c
Faulting process ID: 0xb74
Faulting application start time: 0x01d3b5c77355520d
Faulting application path: C:\jobtalk\jtJobTalk.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report ID: d1374fd2-21ba-11e8-8272-d050999dc03c
I tried sfc scan and no problems were reported.
On yet another computer (running Windows 7) I get the error
A new guard page for the stack cannot be created
How can I further troubleshoot this issue?
I am afraid to update the VS version on the good machine in case this causes me to be unable to release.
[Update]
After putting in some calls to MessageBox.Show I have established that the error was caused by an object referencing itself from within it's own constructor.
It has taken me a day at least to find this out. I am looking for any pearls of wisdom that could have helped me diagnose the issue in an easier way.
Exception code: 0xc00000fd
That is STATUS_STACK_OVERFLOW. A very common mishap, and hard to debug, so much so that they named a popular programmer web site after it. You are getting the raw version of this mishap with little assistance from the debugger. Always an issue in interop code, you can't rely on the managed debugger engine to help you diagnose it. Google is your best bet, all of the top hits for this phrase help you get on the right path to start fixing it.
If I build the COM library on a particular machine...
That is being unlucky, turning over the wrong stones to look for a cause can bog you down for a while. SOE is never caused by build problems or a buggy VS version, always a coding mistake. The most basic reason it would occur on one machine but not another is that you don't test the program with the exact same data. Or made a quicky coding change that looked very innocent, but wasn't.
if (edge.Extra == null)
That is one of the very common causes for SOE, a buggy property getter. Something like this:
public class Example {
private Foo edge;
public Foo Edge {
get { return Edge; } // Oops, meant edge
}
}
You can certainly look at this for a while and never see it. It would be nice if the compiler had a diagnostic for it, but the C# compiler does not have the necessary plumbing to ferret this out. The other very common cause is a field initializer:
public class Example {
private Example foo = new Example();
// etc...
}
Which can easily get more convoluted from there, when for example you create an instance of another class, and that class creates an Example object in its constructor. And the C# language supports writing recursive code, it is one of the standard programming techniques. If that code is any more complex than O(log(n)) then you can always easily crash it with too much data.
...any pearls of wisdom
Yes, there is one. If you don't have the managed debugging engine helping out with exceptions then diagnosing errors gets pretty hard to do. The VB6 runtime can provide you with the exception message, but not the Holy Stack Trace. Info that is lost in the transition between the two very different runtime environments.
But you can have that cake and eat it too, the trick is to get the managed debugger to start the VB6 IDE. Right-click your C# class library project > Properties > Debug tab. Select the "Start external program" radio button and type "C:\Program Files (x86)\Microsoft Visual Studio\VB6\VB6.exe". You can optionally set the "Command line arguments" to the full path of your .vbp project, that way the IDE automatically loads your VB6 project. Use Debug > Windows > Exception Settings and tick the "Common Language Runtime Exceptions" checkbox so it displays the tick mark. This makes the debugger stop on any C# exception, before it is passed to your VB6 code.
Press F5 and the VB6 IDE starts running. Press F5 again to start your VB6 code. Any mishap in the C# code now causes the managed debugger to step in. Usually the display automatically switches to the VS IDE, but sometimes you have to click the blinking taskbar button. You get to look at the code that threw the exception and use Debug > Windows > Stack Trace to find out how it got there.
I'm not 100% sure that this also works to diagnose SOE, the VB6 runtime might step in too soon to allow the CLR to see the exception. I don't have VB6 installed anymore to check. Please try it and let me know.
I'm looking for a little help regarding the win32 exception "error creating window handle".
From time to time our program (WinForms - C#) throws this exception and sometimes the windows even freeze, so that the users have to kick the process to be able to work again.
From the many other threads regarding this problem, I know what I should be looking for, but not extactly where as our program is quite big. So I was hoping that there might be a way to restrict the codelines I have to check... Are the any tools, which can help with this exception?
Short update: I solved the problem.
ProcDump didn't help me much, because I got pretty the same information from our logfiles. However, I was able to reproduce the error in our development environment. Thanks to debugger and displaying the user-objects count in the taskmanager I found the source of the memoryleak - an undisposed texbox which was created dynamically.
Thanks again for the tips!
If this issue happens inside the debugger, you can set the debugger (I will assume Visual Studio as you're using C#?) to break on throwing an exception. In your case you would want to set an exception breakpoint on (I think) System.ComponentModel.Win32Exception.
Again assuming Visual Studio as your IDE, on the "Debug" menu is an "Exceptions..." item. This allows you to tell the debugger to break when specific exceptions are a) thrown, or b) unhandled.
Under Common Language Runtime Exceptions, expand System.ComponentModel, and enable the checkbox in the Thrown column for System.ComponentModel.Win32Exception.
Then just carry on as normal. If during debugging the exception occurs, it should break into your program and allow you to see where it's happening.
Edit: If you can't reproduce the problem on your development machines, see if you're able to set up the target machine to produce a dump when a crash occurs. One way of doing this is to run ProcDump. Run it with the -e parameter to create a dump in the event of an exception. Then you can analyse this back at the ranch.
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
}