so this is kind of a weird error. On one machine from one of our customers (Windows XP SP3) our program crashes when trying to open a filter dialog via ShowDialog().
What happens: The user works as expected he/she does nothing unnormal or wrong and everything he/she does is/was tested on several machines (ranging from Win XP 32 bit to Win 7 64 bit).
Now, after some time he/she want's to use the filter dialog (which he/she did at that point like a dozen times) and the application crashes. You get that wonderful "$applicationname caused a problem and has to be terminated" message from Windows XP, beneath it you can see the filter dialog, partially build (meaning: you can see the window, a scroll bar and transparent 'holes' where the text controls/labels should be.
In the Windows eventviewer you can see an entry like this
Event ID: 1000
Source: .NET Runtime 4.0 Error Re (maybe something stands behind this and it says 'Reporting'?!)
Faulting application $applicationname.exe, version $versionnumber,
stamp $someRandomNumbers, faulting module ntdll.dll, version
5.1.2600.6055, stamp 4d00f27b, debug?0, fault address 0x00446da
Now, what weirds me out: The position where the dialog is opened via ShowDialog, is embedded in 2(!) try...catch blocks. How is it possible for the application to crash? There aren't even logfileentries (something that is done in EVERY catch block we've in that program and it's always the first thing we do) about this crash.
I already uninstalled the application and .NET 4 from that machine, rebooted installed everything again, installed Windows Updates and rebooted again. Same result.
*edit
just noticed something: When I close the message from microsoft, an additional entry in the eventviewer is created:
The process was terminated due to an unhandled exception I guess that's the meaning in english, since the original message is in another language I had to translate
Exceptioncode: c015000f, address 7c9546DA address is always the same
As #Hans said, it's caused by incorrect use of the De/ActivateActCtx winapi functions.
I met the same problem when I write a VB App. using my ActiveX Contrl(MFC). I place a dialog variant in the control class definition.
Like below:
CMyDlg dlg;
So when does the dialog initilized is not in my control. And that made the same issue as you. When the control should be displayed, the error appears.
Related
Hi I'm being driven mad with a bug that i just cant reproduce on any machine i can get direct access to!
I'm just printing a visual from a WPF app. The print code is extremely basic.
"PrinterName" is a simple string of the printer name taken directly from the printer settings.
"usercontrol" is a basic user control with a few bits of text arranged on.
PrintDialog printDlg = new PrintDialog();
printDlg.PrintQueue = new LocalPrintServer().GetPrintQueue(PrinterName);
printDlg.PrintVisual(usercontrol, "Printout");
as noted on almost all machines this code works flawlessly HOWEVER on some machines at some random intervals it causes a hard crash outside the managed code which i cant seam to log so all i get is the event viewer crash info below (personal details removed).
One item of note, i had to build an alternative printing option (doesnt work well) for this program to work on an older instance of windows server due to printvisual using some sort of usercontrol -> XPS -> printing process and said windows server version not having XPS available. This alternative method has never seamed to fail however due to the variances on printers requires a LOT of manual caliberation per printer to ensure the printout is of suitable quality and margin so isnt really a good solution. The above print visial results in perfect printouts 100% of the time on any printer...when its not crashing the entire program!
Faulting module name: ntdll.dll, version: 10.0.19041.1741
Exception code: 0xc0000374 --heap corruption ?
Fault offset: 0x00000000000ff249
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
I've refactored the printing code multiple times. The above code was my solution to this problem as I was previously generating the print queue manually instead of using the "GetPrintQueue", and so solved the issue for most users experiencing the issue for the last few months, however the above has now started crashing on (at least to my knowladge) one system!
While developing a WPF app I encountered this crash.
I tried with/without debugger, Release/Debug configurations, same result.
The message 0xC0000005: Access violation was shown only in Output window, when I started the app VS appeared to be running it for ~10 seconds, then stopped as if I just closed the app normally, but it never showed.
Disabling Just My Code and enabling Break for every exception didn't help.
I have made no changes to the code, and the day before it ran without a problem.
Re-cloned the git repo, still nothing.
The problem was a DirectX overlay app (MSI Afterburner). Turning it off helped.
I went to Control Panel\System and Security\Security and Maintenance\Problem Reports (or Search for "View all problem reports" in Start), the report said Fault Module Name: d3d9.dll, that made me think it could be Afterburner.
I am building a .net 4.5 (c#) app and packaging it with Squirrel for Windows.
As expected, the releasify command creates one Setup.exe file and one Setup.msi. The Setup.exe installs the app as expected on the two windows 10 computers I had access to.
On the windows 7 I used to build the app though, when I try to open Setup.exe, the window where I double clicked the icone goes in "please wait mode" (with the blue progress circle instead of the usual mouse pointer) forever. If I check the processes open at that point, I see three Setup.exe that I cannot kill with the kill process button or via Taskkill command. And all I can do at that point to kill them is pretty much rebooting.
As to the Setup.msi, it seems to do nothing I can see (tells me something like "checking requirements", and once it has, it just closes with no visible effect).
Any idea about what's going on or how I could find out?
Apparently years later this keeps hitting people so I'm posting the answer I had first put in the comments:
Deactivating my antivirus solved the issue >< I wish Avast had told me "hey I'm blocking this" and saved me a few hours
I made a program, which works fine on my PC without any errors, it also works fine on some office PCs, but it crashes without any describable error on customer's PC and some others.
Crashes are completely random, sometime it may crash and sometimes not.
Crashes are not related with any actions, sometimes it may crash when they just look at the program and wait for crash.
Customers send me this beautiful screens and want me to solve this.
There you see common error reporting dialog, but not info about Exception.
My program uses Unity Web Player running in WebBrowser control. It's always run in background on the hidden tab which becomes visible when needed.
Any ideas how to handle such errors?
I think you should first ensure that the environment at your place and that of your customers are identical.
Maybe there're dll or other programs installed at your place (Unity web player as you mentioned for example) or anything in your Registry that may differ.
Else there's no point in getting error on one PC and not on another.
Make sure all dll are well deployed
Check your registry,
Ensure that all related programs are well installed
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
}