I know that running applications in DEBUG (build configuration) thru the visual studio adds a level of overhead but I have a WPF application that I am testing out that is painfully slow in its execution and other functions such as drag/drop of items. When I run the application in Release mode it performs like one would expect, very quickly and without hesitation. I've set up no special debugging parameters or any other watches, settings or breakpoints that would interrupt the application.
Has anyone else run across an issue like this or is there possibly just some setting that can be adjusted? It's not really an issue more of a why is this happening...
thanks.
The garbage collector is much less aggressive in debug mode.
Try watching the memory usage in task manager, the VM Size column is often the most useful.
See if during the slow operations a lot of memory gets released - this will indicate that the collector hasn't bothered doing much work for a while and then has had to kick in a do a larger clean up.
You might check your Output and Immediate windows. You're might be getting a lot of messages thrown in there, especially if you're getting binding errors.
Related
I can set the trace using code such as:
xmlns:trace="clr-namespace:System.Diagnostics;assembly=WindowsBase"
trace:PresentationTraceSources.TraceLevel=High
I can also set the debug settings in Options->Debugging->Output Window->Data Binding.
But I cannot see the trace information as it occurs in design-time.
You might ask why I want to do this. The design-time execution is not the same as the runtime execution, even when I have made the best effort to keep things running the same way. Seeing these traces would be a huge help.
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.
Try putting the following code inside Load event handler for WinForms or Loaded for WPF.
Dim doc As New XmlDocument
Dim nsmgr As New XmlNamespaceManager(Nothing) 'this line throws an exception
Problem is that exception is not thrown, and stack corruption happens. It may have different side effects, depending on the IDE - see below.
Affected IDEs are: 2008, 2010 and 2012 (those I could test). 2010 resets stack state, and returns from sub/handler, like nothing happened (but without proceeding with other statements there). 2012 may warn a user about a failed application and an attempt to run in compatibility mode. Next time after that it runs the same as 2010. 2008 properly throws an exception, but only on default configuration (AnyCPU). Switching platform target to x86 makes the problem reappear in 2008 as well.
Affected frameworks are WinForms and WPF. Console apps and ASP.NET
seem to work fine. .NET v2.0-4.5.
Affected scope is only Load event so far.
Putting this code into a button makes it work.
Affected build
configuration = any. Tried on default Debug and Release.
Why I consider it a bug is because it can leave objects in an unstable state - they did not finish initializing, which is not an expected behavior. What's critical about it is that nobody will know it happened, as it does not throw an exception. Depending on your design, you may end up with incorrect data in your database, which in the worst case may lead to severe consequences.
Does anyone have a good explanation to why this may be happening and if there is a workaround?
The problem is caused by the wow64 emulation layer that comes into play when you target x86 platform on a x64 OS.
It swallows exceptions in the code that is responsible to fire the Load event.
Thus the debugger doesn't see the exception and cannot step in to handle the situation.
This article seems to document well what's happening there,
This previous answer from Hans Passant (to which goes all the credits and upvotes) explains possible workarounds.
My preferite one is to move everything out of Form_Load event and put the problematic code in the form constructor. (Of course I don't know if it is applicable in your case)
I'm trying to debug an issue that happens on service startup. Trying to attach while things are running is failing, windbg times out with an error about a link lock. I think that the error occurs before I have a chance to attach. A sleep might let me attach, but is there a more elegant solution?
I'd like to start up the debugger first thing as the service starts. C# has a Debugger.Launch() method to start a debugger at runtime. Is there an equivalent C call that can be used without .net? Something I could just drop in the start routine.
I can't call DebugBreak because at the time the service has started I'm not under a debugger.
Sleep is certainly a viable approach. It's crude yet effective. Somewhat less crude is to use a good logging framework to output diagnostics. With a sufficiently capable logging framework this can be very effective.
A WPF application. Debugging. Stop on break point.
After few seconds Visual Studio (2008) spontaneously aborts the application execution.
It is never mind what I do after stop on break point: even if I do nothing.
With very simple test WPF application everything is OK with debugging.
Any ideas?
When an application aborts that quickly without warning it's usually the result of a stack overflow in the process. This makes it difficult (if even possible) to do tear downs operations like bringing up Dr Watson.
One thing I didn't quite understand is if the application or VS is suddenly stopping.
If it's the application there is likely a StackOverflow occurring in such a way that VS can't trap the exception. Try disabling Just My Code debugging, turn off implicit function evaluation and break on first chance exceptions. That should hopefully help reveal the problem.
The problem was solved.
To solve the problem the debug settings must be changed:debug->exceptions: and check on exceptions boxes (I checked on C++ and CLR).
(source: ggpht.com)
Result: I can see exception that I didn't see before and I can normally debug my application.
The reason was incorrect vcshost.config file name (my fault).