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!!)
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.
Observed behaviour (everything here is on Windows 10):
I run Visual Studio (tried 13 and 15, both behave the same) logged into user A
After starting up, VS takes virtually no CPU time (<1%)
I log into user B, without signing out of A
VS imediately starts using A LOT of CPU time (~25% on my 4 cores with hyper threading)
I can go back and forth between A and B, and it goes back and forth between low and high CPU usage
This is all without any projects or files opened, though it also happens in that case.
I noticed this because I was originally investigating similar behaviour of a WPF application (after a user reported this issue).
While trying to isolate the problem, I found that even a completely new WPF project, with just a single empty window, behaves exactly the same (whether or not run through Visual Studio).
Through profiling and debugging I found that the app seems to spend a huge amount of time handling windows messages.
Specifically I found that it seems to be almost exclusively WM_PAINT messages (we are talking easily hundreds or thousands of messages per second - as many as the CPU can handle it seems).
No other programs I have running (chrome, skype, sublime text, ..) behaves this way.
Has anybody else seen this kind of behaviour?
And/or any ideas what could cause this, or how I could investigate this further?
Naturally, I cannot fix Visual Studio (unless the problem is with my setup somehow) but I hope there is something I can do about my WPF application.
As per Hans Passant's suggestion in the comments, I reported this problem to Microsoft here:
http://connect.microsoft.com/VisualStudio/feedback/details/2390593/wpf-apps-use-a-lot-of-cpu-time-when-logged-into-different-user
As it turns out this indeed seems to have been a bug in WPF, which is fixed in the current version of Windows 10 (probably specifically since the Anniversary Update (version 1607)).
Hence the solution: Make sure to update your OS.
I'm experiencing a pretty serious memory leak when running WPF 4.5/PRISM 5.0 projects in Visual Studio 2013 on my Windows 7 (64-bit) machine. This has been going on for months and I've tried to narrow it down. The only common denominator is the parameters I've already noted.
It's not any particular WPF/PRISM project that causes the issue. I first noticed the problem when trying out code from various WPF demos on PluralSight and elsewhere. Initially, I had only 8GB RAM on my machine and Windows notified me that I had to shut something down or I'd run out of RAM. I've since upgraded to 16GM RAM and I can run projects for a few extra days without rebooting my machine. Logging off doesn't help. Simply shutting down every running application and waiting (even over night) does not help.
When reviewing the Processes (including the ones for All Users), no process sticks out as taking up the extra memory and what's listed doesn't come close to adding up to what's being taken up in memory. The memory seems to slowly creep up after multiple runs of any WPF/PRISM projects in VS2013. Eventually, I'll find there are gigs(!) of orphaned memory being used up that I can't recover.
I've searched online for any known issues and can find none. I don't know how to nail down the exact culprit either.
Anyone else experiencing this? Any ideas on how I can find out exactly what's causing it and/or how to fix it? I'd rather not have to uninstall/reinstall VS2013, but as a last resort, I suppose I can try it. My luck it will be futile though.
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.
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 :(