it's awesome that you're going through all the diagnostic tools used by MS support engineers. Now the biggest problem is choosing which tool to use when.
By the way, installing a windows service (that's what DebugDiag does in order to collect data) seems a bit uncomfortable in production. Could I take dumps with procdump or windbg and open them in the analyzer to take advantage of the application specific rules, like the one for SharePoint?
Does PerfView need full dumps for that? I've been trying to diagnose an alleged memory leak (it could as well just mean we have to scale it out) in a process who's baseline is 5GB memory usage. The "leak" manifests itself by the fact that after some time (it's a w3wp.exe, which is recycled automatically at 2pm, so it's less than 24 hours of running) the CPU spends more and more time in GC and there is quite a bit of paging (hard faults in resmon). Through perfmon counters, I've noticed that most of memory usage increase is in large object heap.
My question is: will PerfView need to take the snapshot for over 2 minutes just like procdump's full memory dump deos in this case?
is the network I/O provider collecting the same data as the commandline "netsh trace start [parameters]"? Can you use this stuff safely in production? For instance on an Exchange or SharePoint server or Domain Controller?
@problems accessing UNC: I have a similar issue that when I type \\machine\C$\folder\ in the win+R prompt it fails, but typing the same UNC path in Windows Explorer succeeds. Try in Windows Explorer, if it works don't bother your admin - it might be by design in windows.
@anti-pick: Most of these options look like just "different settings from around the system put together on one page" and that's completely OK, but when it says "this super hidden undocumented top secret switch", then you DO NOT want to switch it. It's hidden for a reason, it's undocumented for a reason (obsolete or designed for one single internal usage only or a tool for testers that somehow got left in the system).