Stumped here. Posted a similar question before. We have a pretty large WPF app that on some machines runs great, but on others, all of a sudden, one of the CPU cores gets pinned at 100% (just one core) and the app freezes. It usually seems to happen when showing a context menu or a combobox drop-down (i.e. Popup controls) which is why we can't debug this since no user code is executing at that time. It's driving us crazy because again, on most machines it runs fine, but on a few, it freezes.
The odd thing is when we run it in a VM, it runs great there too! Crazy! Not sure what's causing this, or more importantly, where to even begin to look because as I said, no user code is running.
This happens on only about 10% of our machines, but it consistently happens on those machines. All are clean (i.e. relatively fresh OS installs, no crazy apps, etc.) and mostly identical machines spec-wise: similar CPUs, similar RAM, same video drivers and service packs.
So as I stated in the title, can anyone suggest possible reasons why a WPF app would pin the CPU and lock the app on some computers but not others? We're just stumped!
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
Crappy video driver? Pull two machines - one where it happens, one where not, and start analyzing differences. Could be hardware defects, bad video drivers, anything in that area. WPF uses the GPU to render if one is there.
Since you seem quite to lack options, i would advice to make a new project with just most basic ComboBox in the Window, doing almost nothing. This should work (check :-) ). Then you add features one by one in the ComboBox and test, for instance when you add command, start with empty one. Do this until it 'breaks'. So you know which feature is the culprit.
You didn t say if all was working with software rendering.
Related
For my work I used DotTrace to analyze slowness one of our cliënts experiences in our WPF desktop application.
I used it before to do this which resulted in the conclusion that the DataBase calls where slow which we could then find a solution for.
This time however, I see 75% of the execution time in Native code and no clear slowness in the user code.
I searched some around and saw a few other people with the same question.
The answer there was either that it's normal (previous snapshot also had just a tiny part of execution time in user code, so that seems okay) or that you can analyze it further if you check the box "Collect native allocations" when making the snapshot (which I unfortunately didn't check).
If I check just the user code most of the execution time resides in DevExpress DLLs which are third party UI components. Could you then say that this is moving towards hardware related slowness (see User code part of the snapshot below)?
I used the Timeline option to create the snapshot.
My questions:
Since the snapshot doesn't show a lot of time in true user code (excluding the DevExpress components), could I then conclude that this slowness isn't caused by inefficiency in our code?
Can I tell anything from the native code part of the snapshot (see screenshot below)?
Is Timeline even handy for this case or are one of the other sampling options clearer?
How would I proceed in such a case to move close to the source of the slowness?
Thanks in advance for your help!
Sebastiaan
Native code part of the snapshot:
The native part is always called by the managed code.
The timeline is not efficient in this case. Here you filtered only the native part.
For this kind of analyzing, i recommand using the Sampling mode where you have a better view of your hot spots. The native part will still be there but you can see which managed code called it.
I have a couple issues with it:
media fails to play and continues to fail until the application is restarted
audio plays normally but video is in slow-motion and will not play normally until the application is restarted.
there's no way to reinitialize other than an app restart. (that I know of)
there's no real solid way to know if a video is rendering. I can observe Position to verify it is playing but it's not a guarantee there's any video output.
I run two instances of an extended version of MediaElement in my WPF app which hinges on their stability. After many tests I've concluded that it's the highest performing video player out there, above MediaKit and vlcdotnet, due to using solely GPU to decode. I've encoded videos in WVC1 (Windows Media Video AP#l3 VC-1) for 1080p quality and relatively small file sizes. Eventually after several plays the videos will fail to play, at which point the MediaFailed event is fired and subsequently stops working altogether until the application is restarted.
It is my understanding that when it fails like this, it's a core failure within the underlying Windows Media Player OCX control and it cannot be fixed in any way other than a full application restart. Has anybody found any reliable workarounds for these issues? Mum's the word over at the Microsoft forums...
Answering my own question here to possibly facilitate future SO'ers who might run into these issues. The issue lies in WPF, it is not planned to be improved. For a more reliable solution with minimal overhead, try WPFMediaKit.
I have a standalone WPF application running on .NET 3.5. Every so often, the display simply freezes up for several seconds. This is most noticeable on screens where something is being updated often. Here is a video showing the problem.
While the display is frozen, the interface remains responsive (video).
I've come across some other posts with similar problems who attributed it to a SW/HW rendering issue. To be safe, I disabled HW rendering altogether, but still have the problem.
I ran a file monitor during the freezes to see if there is some extraordinary file access or activity going on, but nothing is out of the ordinary.
Final note: The target platform is a small touch-screen panel PC without much memory or horsepower (512 MB). I only see this issue on the target, never on my development PC, which has much more in the way of resources.
UPDATE
I thought I had fixed the issue by removing some animation code, but it did not work. I am still encountering the problem and I'm at the end of my rope.
Here's some more things I've tried:
Upgraded to .NET 4.0. Same behavior.
Added debug code to all methods that may be invoked via DispatcherTimer (which are called on the UI thread) to make sure none of them are holding up the UI.
I'm really stumped here and have added a bounty. As I mentioned, the problem only occurs on the target PC (link).
I tend to suspect either .NET GC or the OS swapfile when this kind of behavior shows up.
For the former, you could try the .NET performance counters to monitor for suspect activity.
If the device has a swap file, you can disable it and see if the behavior changes.
As others have said, a profiler (or some what of isolating what condition is inducing the delay - even just attaching and breaking the debugger when it occurs) would be a good way to get more information.
Did you tried to profile the application on the tested system? Using a memory and/or performance profiler?
You could get some good informations out of this type of test : some .Net profilers
And here's one for WPF : WPF profiler from microsoft
The culprit was the following method call:
new HwndSource(new HwndSourceParameters());
This was added to my application because it patched a memory leak problem in .NET 3.5. This work-around can be found here. If I remove this call, the rendering issues go away.
I took out the call and fixed the memory leak in another way (removing storyboard animation and using code behind instead)
I'm facing an extremely weird bug here and I'm not really sure If I'm following the right path to solving it or even how to solve it.
Here is the problem I'm facing: I start debugging a WPF application which uses log4net, NHibernate and LINQ to NHibernate, and when I try to get an Entity from the database my application and sometimes VS hang for a lot of time, and after a while an exception dialog opens showing a message containing the following information on a ContextSwitchDeadlock MDA:
The CLR has been unable to transition from COM context 0x34fc1a0 to COM context 0x34fc258 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this
I copied the code files to a new project and deleted the old project to see If I could make this message disappear, thinking it had something to do with my configuration. I started adding few things at a time to see what was causing it, and when I included log4net configuration code the bug appeared again. First I included it through AssemblyInfo and later trough code configuration on application startup, and absolutely nothing changed at all :(
So, here are my findings:
It only happens when I'm using log4net.
It happens when NHibernate loads an Entity from database (lazy loading).
I don't know what might be the source of this bug. It only happens when debugging in Visual Studio. I've tried following the steps on the "Enabling and Disabling MDAs" section of the following page: http://msdn.microsoft.com/en-us/library/d21c150d.aspx, but that doesn't work either, VS still hangs and it's memory usage increases.
When I run the program normally none of this happens, so I'm pretty sure this is not a deadlock situation, as this question suggests: contextswitchdeadlock (I've also tried the solutions posted there).
Because of that, I've decided to disable log4net and enable it again when deploying my app.
I'm posting this question to find out if somebody else has faced this bug or if somebody has some suggestions on how to solve it. Finally, it might help somebody else facing this very same problem.
When using the DebugAppender all the entities in the databases are loaded and all its data written to the debug output. That was causing the ContextSwitchDeadlock MDA since it tookmore than 60 seconds to run.
Disabling the DebugAppender solved my problem.
Thanks to Mauricio Scheffer for the tip.
There is a quite big LOB silverlight application and we wrote a lot of custom controls which are rather heavy in drawing.
All data is loaded by RIA service, processed and bound (using INofityPropertyChanged interface) to the view.
The problem is that first drawing takes a lot time. Following calls to the service (server) and redrawing is quite fast.
I used Equatec profiler to track the problem. I saw that processing takes a couple of miliseconds only so my idea is that the drawing by SL engine is slow.
I'm wondering if it is possible to profile somehow processes inside SL to check which drawing operations are taking too much time. Are there any guidelines how to implement faster drawing of complex custom controls?
Short answer is - No, there's no super easy way of figuring out why your application is slow.
Long Answer:
I have never used Equatec profiler for Silverlight but it seems similar to dotTrace. Either way, they both end up showing the same information as xPerf.
Basically the information you should have in front of you is saying which methods and classes took up the most time to execute.
If that information points back to Silverlight framework graphics engine (agcore.dll and npctrl.dll), you'll have to start a slow process of figuring out what you did wrong.
At this point I strongly recommend that you'll watch every single talk Seema Ramchandani gave about Silverlight performance. Specifically PDC08, Mix09 and Mix10.
Step #1 of perf optimization: Measure. Measure. Measure.
Have a clear baseline of what you're trying to improve, and set a numeric expectation to when performance is good enough.
That way you can verify that your changes are having a positive impact on performance.
Step #2 of perf optimization: Start removing stuff.
In your case, I'd start commenting out controls out off the form. When perf massively improves, you've found your culprit.
Step #3 of perf optimization: Try to fix the weak link.
That's how I would go about solving this issue.
Sincerely,
-- Justin Angel
Try profiling with the Visual Studio profiler in order to get a good measure of your managed code and the native code executing within Silverlight. The profiler will help point you to where you're spending the most of your time (what the hot path's are) and whether or not your spending it in framework (SL) code or your own code.
The basics of profiling are:
Open a Visual Studio Command Prompt (as admin), 'cd' to the directory where your DLL and PDB files are (typically your "Debug" folder)
VSPerfClrEnv /sampleon
VSPerfCmd -start:sample -output:somefile.vsp VSPerfCmd -globalon VSPerfCmd -launch:"c:\Program Files (x86)\Internet Explorer\iexplore.exe" -args:""
VSPerfCmd -shutdown
VSPerfClrEnv /off
You can find detailed instructions on using the profiler on my blog: http://www.nachmore.com/2010/profiling-silverlight-4-with-visual-studio-2010/
If you find that you are spending time within Silverlight, track down the code path to see where your code is triggering the expensive calls, so that you can then investigate specific solutions based on the cause of the slow down.
Hope that helps,
Oren