Comments

We taped more PerfView episodes than expected, and then we needed to slot in the WMI episode to cover the C9 Studio closure over the break. This caused the DebugDiag episodes to get way out of whack of what was expected when we taped them months ago.

My OCD isn't happy either.

[EDIT] I just fixed some of the ordering. I flipped 119 and 120 so the 7 PerfView episodes are now all together, next is the WMI episode, and then the 4 PerfView episodes. I can't fix the filenames on the media files though. :(

We'll get it all back in to alignment on the 26th Jan.

@androidi: Email me (defragtools@microsoft.com) -- I haven't seen this issue at all -- we should look in to it.

Instead of using my project, maybe try the nuget package import yourself. That might fix it.

Congrats everyone -- what an awesome legacy!!!!

@gt65345: It's a Nokia 521 (running WP 8.1).

(I was texting that I was running late 'cos the 1hr shoot ran 2.5hrs - due to us geeking out all the time, instead of filming)

@Ben: Stay tuned -- I'm prepping a new mini-series on managed debugging at the moment. Instead of coding the logic in C++, you interop in to C# and do the logic over there with help from CLRMD.  Hopefully will get Lee Culver on to co-host (the developer of CLRMD and SOS).

(If you can't wait, email me and I can get you started with what I have so far)

@mgrzeg:@Dono:  After a short break of the end of the current C++ focused series (Ep 9 is the last), we'll cover CLRMD - the framework that allows CLR inspection from a debugger extension.  We are trying to get Lee Culver (the SOS and CLRMD developer) to host the episodes.

Crash on Ctrl-Home-Home

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kbdhid\crashdump]
"Dump1Keys"=dword:00000020
"Dump2Key"=dword:00000050

@aallidina: Rename them and then put the symsrv.dll from the debugger folder there. That might make it work. If it doesn't, get a DBGHELP trace and email it to me (defragtools@microsoft,com)

md c:\My
md c:\My\DbgHelp

setx DBGHELP_DBGOUT 1
setx DBGHELP_LOG C:\My\DbgHelp\DbgHelpLog.txt

@aallidina: Well that's annoying. What location is symsrv.dll being loaded from (looking in the Process Monitor log).

The versions in system32 isn't the full version. You need to use the version that comes with the debugger (same story goes for dbghelp.dll).