We Keep Coding

Why is VS 2015 stopping diagnostics session is taking forever?

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.

C# WPF app with MahApps failing to display in Windows 2008

So this is a weird one.
I created a WPF application using MahApps for the GUI. So far my testing indicates that the app works fine on several different machines. Of course this is not the case on the client's machine.
The client makes use of Terminal Services and Windows Server 2008R2. Several users can be logged into their own version of the server at anytime. The app starts up fine once or twice, but after a day or so, it no longer opens up.
The app doesn't show up in the Application tab of Task Manager, but its process can be seen to be running in Processes Tab of Task Manager.
To be honest, I'm completely stumped. I had a look at the event manager log and couldn't find anything indicative of a problem. (Of course I might have missed something). I saw another SO question suggesting to disable hardware acceleration, but I'm not if that would help.
Any and all ideas would be greatly appreciated.
EDIT:
I thought I might mention the only thing that helps is if we restart the client machine.
EDIT:
I think I have isolated the issue to integration with Twain (should probably have mentioned that as another possible factor). I think the Twain library (unmanaged code) somehow stalls without sending back an error. Disabling it has "fixed" the issue.
This somehow relates to Twain and multi-session setups. I'm almost sure of it.

First you can analyze the wait chain in Windows Resource Monitor to check if there are any resources the process is waiting for. (You can find more information about the wait chain here or here.)
If you don't find any viable suspects there, you can create a memory dump of the hanging process and analyze the call stacks. If you don't know how to create one, you can read about it here. If you want to use Windows Task Manager and your OS is 64-bit then please be aware that you need to use the same bitness of Task Manager as the application.
That is: If your application is 64-bit then you have to use C:\Windows\System32\taskmgr.exe and if it's 32-bit you have to use C:\Windows\SysWOW64\taskmgr.exe. If you forget this important step you'll just get an unusable dump full of gibberish.
After you got the memory dump you can either load it into WinDbg (using the same bitness as the application) or Visual Studio (best to use 2015 or later) and analyze the call stacks of all running threads.
You can download WinDbg here and read about the necessary WinDbg configuration here. For the list of all threads you need to use this SOS command.
If you need help in loading memory dumps into Visual Studio you can find more information here.
After you've looked at the call stacks you most definitely find the answer what is waiting on what resources and is thus preventing the shutdown or startup of the application. It can either be a classic deadlock or an external resource like writing/reading of a file or some other waiting without a timeout like accessing a database or an URL that can't be reached at the moment. And of course it can also be just an infinite loop - if it doesn't consume much CPU then perhaps with some kind of DoEvents in between.
And last but very not least: If you are really interested what can be analyzed if an application hangs you can read about an example analysis done by the absolutely awesome great Mark Russinovich here.

Application becomes sluggish after minimizing

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.

Ways of isolating cause of unresponsive Winforms GUI

I have a large-ish Winforms application written in C# which is periodically unresponsive. The issue seems to occur once the application has been use for an hour or so. Exact timings are difficult to gather as users often go off to work on something selse, get back to it and find it has become unresponsive.
I think a memory leak can be ruled out as I'm not seeing excessive memory usage (I've asked users to send a screenshot of the task manager and memory usagage is the same as I would see when the application is runnning normally)
Similarly, CPU usage is normal (single digit %)
As I've so far been unable to recreate the issue on mydevelopment PC I am planning on sitting next to one of the affected users and mirror every action the user performs in order to recreate this. (I'll be setting up a laptop to RDP in to my main PC)
Recreating the issue is one thing, but I'll need to find out what is actually going on in the application.
Could anyone tell me if running in debug mode (through visual studio) will be sufficient or will I need to do something different?
I've searched through a few posts and I've seen mention of profiling software, however I'm not sure if this would only help with general performance issues or memory management issues.
Alternatively, if anyone has come across similar freezing issues then do you have any suggestions of the kind of causes for this?
Some technical details: Aplication is C#, compiled against .NET 3.5, winforms GUI. There are a few external libraries (most significant is ComponentFactory Krypton Suite). Data access is to a Microsoft SQL Server 2005 database. The solution contains 39 projects, I'm not sure if that might have something to do with it?
Any suggestions/pointers would be greatly appreciated.

The application is working much more reliably now, freezing issues still occur on occasion but nowhere near as often as before.
The issue appears to be related to the endpoint security (in this case, Cisco Security Agent) present in the environment I'm working in, application has been whitelisted and has has significantly rediced the instances of application hangs. The development system I work on does not have this endpoint security present, so it didn't show up in early stages of testing.
Thanks for all your feedback, I think there are still threading and garbage collection issues that need cleaning up, hopefully this should sort out the last few issues.

log4net DLL gets corrupted (set to all zeroes)

We've recently started seeing an issue where log4net.dll is corrupted - specifically, it is the right size but contains all zeroes. This causes BadImageFormatExceptions (ultimately wrapped in TypeInitializationExceptions since we tend to initialize our ILog instances statically in each class). This happens sporadically and without a discernible pattern. Uninstalling and reinstalling our app seems to "fix" it, in that we haven't (yet) seen the issue twice on the same machine - but that could just be coincidence.
Our application consists of a Windows service and a "regular" Windows app which communicate via named pipes (nothing too unusual). We've used log4net in the regular app for a long time (before I joined the project), but only recently added log4net to the service. We initialize it using the same mechanism in both applications, specifically:
[assembly: log4net.Config.XmlConfigurator(Watch = true)]
And we typically instantiate ILog instances statically in each class, i.e.:
private static readonly ILog _log = LogManager.GetLogger(typeof (SomeClass));
So far, we have considered the following but without any hard evidence to lead us to a conclusion:
An installer issue. We're using a pretty standard MSI installer, and this file is simply copied normally as part of the install. It's not the first or last file copied. Furthermore, we've seen at least one instance where the issue didn't manifest until a day or so after the install (whereas most of the occurrences have happened shortly or immediately after install). We have, however, recently cleaned up the installer so there have been changes there (unfortunately I can't speak to them in great detail, as the installer work was done by someone else and MSI is not something I'm deeply familiar with).
Interaction with anti-virus software. All the machines that we've seen the issue on (4-5) have the same AV software (Sophos), but there's no indication in any Sophos logs of log4net getting flagged or quarantined.
Something related to using log4net in the Windows service application.
As you can see, we have reasons to doubt #1 and #2, but haven't yet ruled anything out, and have very little evidence for or against #3. Since this is our first release where we're using log4net in the service, it obviously seems suspicious that we're now seeing the DLL get corrupted - but we also had our dev, QA, and beta testers using early iterations of this release for several weeks before this started occurring, so there isn't an obvious correlation with respect to the timing of the change.
We've also tried automating the uninstall/reinstall process to run repeatedly to see if we could shake anything out (nothing after several thousand installs). We've got all users in our office running with ProcMon so that if we see it again, we can hopefully see what touches the file, but that means at this point we're in a waiting game.
Any thoughts on how we could more definitively rule some of our possible causes in or out, or any info from someone who's seen this issue specifically would be greatly appreciated!
UPDATE:
We haven't seen this as much recently, though that's probably due at least in part to lower usage of the installer. However, one key change that we made recently was turning off publisher evidence for the service application (see here: http://msdn.microsoft.com/en-us/library/bb629393%28v=VS.90%29.aspx)
We made this change (as the above link recommends for service applications) to improve our startup times since we were occasionally seeing the service time out and fail to start. However, we also haven't seen the log4net.dll corruption issue since we made this change. Is it possible that by disabling this feature, we are bypassing some sort of operation that could potentially mangle the log4net.dll (which is a strongly-named assembly)? We don't want to assume we've fixed the issue just because we haven't seen it in a few weeks, since we don't have any hard evidence and thus it could just be coincidence
Again, any thoughts would be much appreciated.