I have several applications in WPF that periodically crash on 2 different servers (a dell poweredge and a HP proliant). The problem is that the WPF applications both crash within d3d9.dll. Rebooting the servers always fixes the problem. The problem only occurs a few times a month. Both servers are running Windows XP instead of Windows 2003.
Here is the event viewer application log entry for the crash
Faulting application iqlayer.exe, version 5.3.1.14, stamp 4a9d0d63, faulting module d3d9.dll, version 5.3.2600.2180, stamp 41109693, debug? 0, fault address 0x0003a756.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Once this problem occurs, all further WPF applications will not run until I reboot. I even tried running a test application which showed a blank window. The test app crashed immediately on start at d3d9.dll.
I found this KB which i think is related to my problem. However, i didnt install directX SDK on my server and dont know where to uncheck "Break on D3D9 Error".
Did you upgrade your video card drivers to the latest version?
I reckon there is no answer. I have rebooted the server and cant reproduce the problem :(
Related
So I have spent the better part of two days troubleshooting a very weird issue. At no point running my application on the development workstation or a physical workstation did I ever encounter any issues running the application.
The app has reached a point in the development lifecycle were it was time to start doing more targeted regression testing. This included running the application within virtual machines as I wanted to support the application running in virtualized environments.
Well upon testing in virtualized environments I noticed a very weird issue randomly any command I had binded that opened a child window would sometimes not work. The child window will not render and the button would be greyed out due to the canexcute of the command giving false since it thought the command was still running. This issue cannot be reproduced on a physical machine and have tried greatly.
After research I saw a lot about virtual machines and wpf rendering and people stating to force software rendering instead of allowing hardware rendering. This did not work either.
Further research/testing found this didn't have to be a task that rendered a simple child window and it could be any task that would lead to this random issue.
After beating my head I have found these articles
https://www.gresearch.co.uk/2019/12/20/deep-dives-in-debugging-when-it-really-isnt-your-fault/
https://github.com/dotnet/coreclr/issues/26990
https://github.com/dotnet/coreclr/pull/10065
Long story short is that this is an issue with .net 4.8 and if I run in a virtual machine running 4.7.2 these issues are not reproducible. I am going to leave this open though as I did notice something odd after discovering this information and testing further.
I have discovered that if I run application on a virtual machine with .net 4.7.2 with TWO or more vCPUs that these random issues are not reproducible. But if I run on a virtual machine with .net 4.7.2 and ONE vCPU the issue still arises. Furthermore if I run application on .net 4.8 with TWO or more vCPUs the issue arises. Lastly if I run on .net 4.8 with ONE vCPU the issue is not reproducible.
I'm developing WPF textual testing application.
Everything is OK, but sometimes my app stops responding.
Using Process Explorer I've found out that there's a problem in wpfgfx_0400.dll. Moreover, in most of cases entire OS could stop responding after a while. I think it could be video layer (driver?) issue, because music continue playing.
All windows/.net/video driver updates are installed. Windows7x64, .NET4.0, Radeon HD7700
What could be the problem?
From my experience, such errors are almost always a driver issue. You can try to verify that this is hardware/driver related problem by forcing wpf to software render mode - see this answer and this answer for more info on how to do it. If you don't have any problems in software mode then it's a driver issue, so you can try some older driver versions and see if it goes away.
everyone. I am developing the LWF version WinPcap. It is already finished and under internal test currently. A colleague shared a Win7 x64 virtual machine with me remotely. Then I tried to install my new WinPcap installer on it and the machine just got frozen when installing the driver. The strange thing is that only this machine has this problem. I tested my own Win7 x86/x64 and Win8 x86/x64, no this issue.
I seem to encounter an alike problem before, but it is a debug version. My machine got recovered when a kernel debugger like WinDbg or VS2012 was attached. I thought this is a "int 3" problem. But the driver in this installer is a release version. So I don't know if this is because of the same issue. It is difficult to attach that remote machine becasue we are from different countries.
Also this should not be a deadlock issue like NdisWaitEvent waiting for an impossible event. Because I encountered that deadlock before, it only blocked the network part of Windows. Like froze the network properties window, stopped you from rebooting and so on. You can still use the other part of Windows.
So why this frozen problem occurs?
Here is all the code of my driver if you like to read:
https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/packetWin7/npf/npf/
The installer and other info are as below:
(Revision 32149)
Entire code base:
https://svn.nmap.org/nmap-exp/yang/NPcap-LWF
The installer only:
https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/installer/winpcap-nmap-4.1.3-NDIS6-1.2.0.exe
Build instructions:
https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/README-builds.txt
We have a higher-end Win7-64 Dell precision workstation notebook with an i7, 8 gigs of ram, tons of hd space and running dedicated AMD graphics. The machine is about a month old. It was one of the highest-end we could get at the time.
What we're experiencing is when we run our WPF/SQL Server (local) app, it tends to hang and stall, sometimes completely crashing, but mostly just hanging until we force it to close. However, the exact same installer running in a VMware virtual machine running on that same machine runs flawlessly. Actually, the VM install runs better than a lot of native installs on other machines. It's very snappy with no hangs or hesitations at all. But again, same app, same installer running direct in the OS, and we're back to the issues above.
We've ran all Windows updates.... we've tried completely reinstalling everything... .NET frameworks, SQL Server, video drivers, even updated the BIOS and checked for rogue services but it still happens.
At first we thought it was Symantec AV's real-time protection because when we first shut that off, things started getting snappy again (and slowed down and froze when it auto-re-enabled itself furthering this hypothesis) but then it just started slowing down again, and more surprising, that same AV is running in the VM without issue! Checked the exceptions but there weren't any.
We even tried forcing WPF to run in software-render mode but again, nothing.
Now the odd thing is this only seems to be happening on this and a few other machines, but we can't seem to find anything in common except they're all running Win7 64-bit. As such, we have absolutely no idea where to start. And since most are hangs, not crashes, we can't even look at the crash reports.
So can anyone give us any idea what else we can look at? This is holding up us shipping a three-years-in-the-making major release of our software so to say this is a show-stopper would be an understatement. We've been stumped for about a month now and getting nowhere fast.
Found it!! Turns out there's a bug in .NET 4.0 regarding UI Automation and the changes MS introduced. Here's the info, and the fix! (Note: Even if you call MS, they will send you a link, but it's always a broken link. I managed to track this down manually.)
Note: Their article talks about a specific case that causes this behavior, but if you google around, you'll see tons of issues around hangs related to those DLLs. The latest is they're promising a fix in the .NET 4.5 runtime (from a MS post on this issue.)
Here's the KB article...
http://support.microsoft.com/kb/2484841/en-us
...and here is the actual hotfix.
http://archive.msdn.microsoft.com/KB2484841/Release/ProjectReleases.aspx?ReleaseId=5583
Apparently the VM didn't suffer from this. We weren't sure if the VM had the hotfix applied or not or if this only happens on non-virtualized machines. Still, this solved all of the issues and the app is now snappy again. (Man, was this fun to track down! Ugh!!)
I just discovered this problem today, and I had no idea what caused this problem. My project had been developed for few months.
I have a project(solution), with several projects in there, it works well if I write and debug, by pressing F5.
The problem occur is when I press Ctrl+F5 (to skip debug mode), or run directly from double click the exe, it crashed. The errors dialogs that pop up every times are different, but OutOfMemoryException is the most frequent one.
I had checked to make sure all my projects are .Net 3.5
I put a MessageBox.Show("something") at the beginning of my main project constructor, but it never reach.
I use some registry cleaner to clean/fix my registry, scan for viruses.
I had try to read the meaning of each error and exception, but still no clue why it happen.
These are a series of screenshots if I press Ctrl + F5. (FutureGenerator is some random name I gave to my project.)
Series of screenshot if I run the app from my debug folder, FutureGenerator.exe
I suspect this is caused by framework crashed during Windows Update, but I removed those update that I performed recently, still same. The exe file works on other non development PC, but I don't want to reformat my PC or reinstall my VS, yet, because it's a painful process.
Any idea, anyone?? Million thanks.
You mention v3.5 but the very first screenshot is about v4.
Try repairing your Framework 4 and/or VS2010
I found the problem. It's actually because I added FutureGenerator.exe into Application Verifier by Microsoft. The verifier only support debugging testing.
After I removed FutureGenerator.exe from the Application Verifier, everything's ok.