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.
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'm having a very odd problem.
We wrote a Windows Phone 8.1 app, and upgraded it to UWP. The debug version of the app works great, however, when I run it in release, I get this error:
Internal.Runtime.TypeLoader.TypeBuilder+MissingTemplateException: Exception of type '{0}' was thrown., Internal.Runtime.TypeLoader.TypeBuilder+MissingTemplateException. For more information, visit http://go.microsoft.com/fwlink/?LinkId=623485
When trying to open a specific ViewModel (working with MvvmCross). It happens only to this ViewModel, though it doesn't seem special in any way.
Note that I'm compiling it with .NetNative enabled. If I disable it, it works fine, but I can't release the app to the store without it.
Any help would be greatly appreciated.
That's one of the runtime exceptions in .NET Native. Most likely you can work around this by adding something to your Default.rd.xml file.
To properly diagnose this I'd recommend enabling .NET Native compilation for the DEBUG configuration of your project (Project properties > BUILD > Enable .Net Native checkbox). Then, set your debugger to stop on first chance exceptions.
If you can move to Update 1, the messages are a bit better.
After digging in a bit, I'd love to know what it ends up being. It's pretty uncommon to hit this type of error so it would be great to know places where we can be better. You're always welcome to send specific feedback to us at dotnetnative#microsoft.com.
It appears the problem was that the offending ViewModel had an Init method that returned a Task:
public async Task Init(...)
Fixed by changing it to void:
public async void Init(...)
Not quite sure why, but it works...
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.
C#, VS2010, WinForm application:
Sometimes I do have the problem that I get an error message when opening some of my controls / forms. All code compiles and the application runs properly. Opening the control in the designer gives me:
The designer loader did not provide a root component but has not indicated why.
From my experience I can tell, it is usually something in my code which does not get properly initialized, e.g. a property is not set which is somehow available at runtime, but not when opened with the designer. The only issue is, that the root cause is hard to find.
Q: Is there a chance to somehow use the debugger when the designer opens my component in Visual Studio 2010? That would help a lot and the problem tackling is most likely a matter of minutes then.
Remark: Just to make this clear, I know how to use the debugger ;-), I only have no idea how I could tell VS2010's designer to open my control in Debug mode.
As of 2nd SEP 2010 added:
Thanks for your help. Basically it is the MSDN Library article describing how to do it.
I have managed to set it up and run the second instance
(there was not much to understand how to do it).
It only fails in my case, because the 2nd VS2010 instance (debugging Design Time) fails to find the
symbols for my custom control. I have added the symbols manually under Debugging / symbols. No
result, still "Breakpoint won't be hit because of missing symbols"
BTW, using this approach it is helpful to exclude some stuff from the symbol loading (via modules window), because this will safe a lot of time.
Now if have to figure out how to get the symbols resolved and then I can tackle the issue.....
The vast majority of design time problems with custom controls are caused by code in the event handlers or method overrides in your control running at design time as well as run time. That's normally desirable, you get instant feedback when you change a property in the Properties window for example.
But not desirable when the code depends on something that's available at runtime but not design time. Like a dbase connection or a file that's stored in the build folder. That can generate exceptions and Visual Studio isn't very robust against handling exceptions at design time. Worst case, you can crash VS to the desktop without any diagnostic. But anything is possible.
Review the code in your control and make sure that the bits of code that should only run at runtime are wrapped like this:
if (!DesignMode) {
// etc..
}
Hard cases can be diagnosed with the debugging tips in this MSDN Library article.
To debug your control in design mode, you need two instances of Visual Studio. In the first instance, open the project which contains this control source code. In the Project Properties, Debugger, set command line which calls another Visual Studio instance (msdev? don't know exactly for VS2010 - take it from the shortcut), Then execute "Start Debugging" command. Another Visual Studio instance starts. In this instance open client project which uses your control on the form.
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.