I am trying to analyze a WPF project (WPF, .NET 4.6.1, EF 6, Moq., on a i5 machine with W10 64 bit) using the performance profiler with only "Timeline" activated.
Problem is that on stopping the program I am stuck in the "Report.....diagsession" tab with the message "Microsoft Visual Studio is stopping your diagnostics session" and the rotating hourglass. Some times it just times out, other times I get to the report eventually, but 5 to 20 minutes later.
Interestingly the time waiting for the diagnostic session to stop is included in the report. It is like the process collecting the data does not get the message to stop recording.
Using Windows Resource Monitor I have noticed VsStandardCollector.exe writing huge amounts of data to a subfolder in "C:\Users\XXX\AppData\Local\Temp\". About 9 Gigabyte in my last try, covering 10 minutes in total while my application only ran for 30 seconds before I stopped it.
Anyone with an idea what could cause the delay in stopping the session?
CPU and disk use is very low during waiting (< 5%)
Recently I've learnt about PerfView tool that is used for performance analysis even inside of Microsoft. It's much cheaper than VisualStudio, in fact it is free.
So you may use it to analyze performance of Visual Studio to answer your question or even better - use it to analyze performance of your own WPF application.
It seems if your project is consumes more than 4 GB, standard profiler is extremely slow and sometimes dead hangs on some unknown invisible internal problem.
I manage to go through this by steps below
Build Release version
Run Profiler with State Paused.
Give VS give more permissions for you debugging account if VS ask for it.
Activate profiler for short period of time.
Close application
Wait 10-20 minutes or more to generated report.
Related
Environment:
Visual Studio 2015 Update 1
IIS Express 10
Moderately sized MVC web application
.NET Framework 4.6.1 x64 debug builds
Newer Core I7 laptop, plenty of ram, SSD drive
Making a small change in one projects .cs file, hit the green arrow to test out the change. It takes about 8 seconds for the build to finish and Chrome to pop open a new tab. Not bad. But then it takes about ~30 seconds for the first page to show up.
What can be done to reduce that delay? Would pre-compiled views be the first order improvement here? What are some of the best current techniques to achieve that?
Try installing Glimpse. Correctly set up it will show you where the delay is including the database calls and their duration etc.
Install Redgate Ants and step through the code locally (potentially pointing at the production database if this is a live problem), this tool should be able to tell you where any slow down is.
One of the features is:
Jump straight to the slowest activity
The call tree in the .NET performance profiler shows you data for
every method and identifies the most expensive methods, database
queries, and web requests
There is a 14 day free trial, which should be enough time to diagnose your problem.
I have a C# .NET 4.6 console application that is supposed to run continuously (over days/months). However, after a non deterministic duration, all running threads will freeze for no apparent reason (CPU usage is at 0%, memory is not particularly high), and trying to attach the application to an instance of Visual Studio 2015 for debugging will fail (pressing "pause" will cause Visual Studio to stop responding!).
I inspected the parallel stack traces (captured via a dump in the process explorer) and could not find any sign of a deadlock (which would otherwise be the obvious culprit).
Here are for example 2 parallel stacks that are frozen (not even in my code but in the DirectoryInfo.cs core library, and ServiceStack OrmLite library), even though there are absolutely no reasons for them to be stuck like this.
I have previously noticed this behavior of freezing on other parts of code so it really seems these libraries are "victims" of the freeze and not responsible for it. Even if there were a deadlock which I could not see, it should not prevent these threads from completing as they are not waiting for anything.
Finally, killing the process and restarting it will always allow the previously frozen operations to run successfully.
Do you have any clue on what could be causing this kind of weird behavior/have any advice on tools to be used to get more insight?
Seems to be both threads are hanging while reading information(execute reader reads data from file, Enumerator trying to read data from file system for directory information). Is the file system is accessible at that point of time? Are you able to access the directory in which the reading is happening ?
There is a C#-program which hangs pretty rare. Execution of the program takes place on a remote machines and to start debugger is not an option. Run external profiler is more realistic, but also conjugate with huge difficulties. How can you determine the point of the program hang without profiler or debugger?
Option "detailed logging on FS" is poorly suited. The program consists of about 20 thousand lines of code and hangs not often.
I have tried Process Explorer but it works very strange (or I have not understood it). If you have managed to "catch" the moment when thread entered into an infinite loop, it is possible to see the stack in that moment. But this thread disappears quite quickly (whether in PE or it is really killed by the environment).
The option to create another application, application-monitor, is acceptable. If you can say how to create a dump of the main process or to obtain information about threads of the main process, it would be great. If you have some ready tools, it would be even better.
When an application crashes, it should normally be logged into Window's Application Event Log. It's not extremely detailed, but should give pretty solid clues anyway without any external tools needed.
To get there, you can either search "Event Log" in the Start Menu or find it in the Control Panel. It is located in the Administrative Tools section.
Once you're in the Event Viewer, open the Windows Logs item on the left then select Application. You should be able to find your application in the list using the Source column.
At the bottom you'll find the error detail, timestamp and a couple more infos which can help you debug your application.
Picture taken from Cyberlink.com
By 'hang' do you mean the program stops working until it is restarted or that the program pauses for an unusual amount of time. If the latter it could be in a heavy GC collection. If it's the former and you suspect some sort of infinite loop then in task manager (or process explorer) you should see it pretty much eating up one of the processor cores. For example if you have four cores and a program in hung in a tight loop, you will see roughly 25% cpu usage in the performance panel (assuming an otherwise lightly loaded machine).
MS supports managed debugging, see Debugging Managed Code Using the Windows Debugger You can use the sos extension to break the code execution and look at the state of the program. You might want to have the programs pdb handy if you take this approach.
After running the WACK (Windows App Certification Kit) locally, I had a failure with the app Crashes and Hangs tests (seemingly due to "startup" not being quick enough - there were no "crashes or hangs") and so refactored some of the startup code to ensure quicker start times.
I got the app to pass the local test ok.
But then I noticed I had somehow caused an odd gigantic memory leak / issue where my c# xaml win 8.1 store app is starting... i.e.
void OnLaunched(LaunchActivatedEventArgs args);
with around ~200MB shown in Task Manager, which quickly ramps up to ~1.5GB before causing the app to crash.
I tried using the VS2013 Performance and Diagnostic tools to try and work out how the hell I'd managed to break my app so totally. And saw the initial ~200MB being used by around ~100
RuntimeTypeCache
objects, and then later on (the 0.7 - 1.5 GB and upwards stages of fun) a
List<object>
with various types in it.
I've tried commenting out code until the App.xaml.cs file does nothing except
this.InitializeComponent();
No joy.
I checked the Package.appxmanifest and removed everything non essential.
I removed references and commented out code until the app was essentially an empty prism MVVM win store app - doing NOTHING... still starts at 200MB !
What on earth is going on?
Well I solved this, and thought the answer might help someone else from pulling their hair out
It seems that one of the performance profiling tools I had used to try and help with the startup time issue had hooked into my app and was actually CAUSING this massive memory usage and subsequent crashes.
I'm not sure which, but I used
WACK - unlikely
Visual Studio 2013 (performance and diagnostics) - possible
Application Verifier (appverif.exe in C:\Windows\System32 - as recommended on the WACK
documentation for solving Crashes and Hangs)
My guess is that it was 3, but this is basically an uninformed guess.
I solved this issue by renaming the .exe i.e. changing the
<AssemblyName>MyNEWAppName</AssemblyName>
In MyAppName.csproj
After this the app returned to normal memory usage (a tiny fraction of the 200MB - 1.7GB I had been seeing)
We have a fairly large winforms application that contains all the following:
Socket Connections
Async Calls to get data from web services thru backgroundworkers.
Timers and other events.
The application works fine as long as someone is interacting with it. However if it is minimized for 30 odd minutes or more (say lunch break for example) and then restored, it feels very sluggish and slow and never recovers its original responsiveness and needs to be restarted.
What could be the connection between minimizing a Winform app for a long time and this unusual unresponsiveness? Perhaps a GC issue but can't find anything. Looking for pointers on what/where to look to solve this. Thanks.
If this issue easy to reproduce - I suggest you to attach profiler when you will restore your application after 30 minutes and see what is going on. http://msdn.microsoft.com/en-us/library/ms182384.aspx
Also you can just attach debugger to see what is going on after you restore your app.