Why does a WPF application in a virtual machine work better than one direct in the OS?

We have a high-performance laptop with a Win7-64 Dell workstation with i7, 8 gigabytes of RAM, tons of hd space and working AMD graphics. The car is about a month. It was one of the highest levels we could get at that time.

What we experience is when we start our WPF / SQL Server application (local), it tends to freeze and stop, sometimes completely crashing, but basically just hangs until we force it to close. However, the same installer running on a VMware virtual machine running on the same machine runs flawlessly. In fact, a VM installation works better than many built-in installations on other machines. It is very fast, without any hesitation or hesitation. But again, the same application, the same installer that works directly in the OS, and we again return to the above issues.

We launched all Windows updates ... we tried to completely reinstall everything .... NET frameworks, SQL Server, video drivers, even updated the BIOS and checked for rogue services, but this still happens.

At first we thought it was real-time protection from Symantec AV, because when we first closed it, everything became fast again (and slowed down and froze when it automatically activated itself, promoting this hypothesis), but then it just started to slow down again, and, even more surprisingly, the same AV works in VM without any problems! I checked for exceptions, but there were none.

We even tried to get WPF to work in program rendering mode, but again nothing.

Now it’s strange that this only happens on this and several other machines, but we can’t find anything in common, except that they all work with 64-bit Win7. Thus, we absolutely do not know where to start. And since most of them freeze, not crash, we can't even watch crash reports.

So can someone give us an idea of ​​what else we can look at? This is pushing us to send out a three-year important release of our software to say that this show-stopper will be an understatement. We were at a standstill for about a month and did not have time quickly.

+6
source share
1 answer

Found! It turns out there is a bug in .NET 4.0 regarding UI automation and changes made by MS. Here is the information and correction! (Note: even if you call MS, they will send you a link, but it will always be a broken link. I managed to track this manually.)

Note. Their article talks about a specific case that causes this behavior, but if you use Google, you will see many problems around the freezes associated with these DLLs. Recently, they promise a fix in the .NET 4.5 runtime (from an MS post on this issue.)

Here's the KB article ... http://support.microsoft.com/kb/2484841/en-us

... and here is the actual fix. http://archive.msdn.microsoft.com/KB2484841/Release/ProjectReleases.aspx?ReleaseId=5583

Apparently, VM does not suffer from this. We were not sure that the VM had a fix or not, or that this only happened on non-virtualized machines. However, this solved all the problems, and the application is now again again. (Man, that was fun to track!)!

+1
source

Source: https://habr.com/ru/post/902611/


All Articles