TechEd 2013 Videos

V

Vir Gnarus

BSOD Kernel Dump Expert
Joined
Mar 2, 2012
Posts
474
Hi Guys,

Recently posted were videos from the latest Microsoft TechEd 2013 conference. This conference was chock full of delicious videos to extract all sorts of debugging and forensic troubleshooting knowledge from. I'm still checking them out, but the ones I've found notable so far are below. I've listed each along with its level (e.g. 200 - Intermediate, 300 - Advanced, 400 - Expert). Here they are:

1. How Many Coffees Can you Drink While Your PC Starts? (300 - Advanced)

2. Sysinternals Primer (300 - Advanced)

3. Hardcore Debugging (4001 - The Good Stuff)

4. Case of the Unexplained (300 - Advanced)

5. License to Kill: Malware Hunting with the Sysinternals Tools (300 - Advanced)


I'll add a link to this thread on the BSOD Method & Tips main article. If anyone finds any other videos that they found relevant and helpful, don't hesitate to add!

Comments or discussion on anything covered in any of the videos is also encouraged!
 
Last edited:
I've just watched the Hardcore Debugging video, I'm going to watch the other videos tomorrow. Thanks for sharing :thumbsup2:
 
Glad you guys like it so far!

One thing that was an eye opener for me was in Hardcore Debugging, where Andrew explained that when an interrupt occurs, it pretty much takes over the stack that's already being used at the time, and then cleans up and lets the original code continue. That was just something that didn't click to me before. I always thought stuff like that happened in its own environment, with its own stack and all, and it just switched to the original stack after it's done, but evidently that's not the case. That gives a whole new understanding to the Trap frames you see when you do a kv on a callstack. It means the portion before and after the trap frame aren't always related to each other. It could be something completely irrelevant that just butted in because it had higher IRQL. It's like someone asks you "I need to do something on your computer real quick" and then after done closes everything he did and lets you continue on with what you were doing. This is how when you see a 0x101 or 0x133 bugchecks that whatever callstacks are retained will often have timer functions at the end of a callstack, because the system butted in using a clock interrupt and did a checkup on all the CPUs to keep things in sync.

I've also noticed that sometimes the interrupt is relevant. It all really depends on looking at the stack and determining just what was going on at the time and making an educated interpretation.
 
Vir, maybe you or someone can explain something to me?

In this video (sorry not at home or I'd check the time) he talks about setting up the symbol file path and mentions setting it to a 'magic Microsoft folder' URL. Can you elaborate on what he means? My symbol file path is very basic. I simply have a folder on my %systemroot% containing symbols, but if there's a much better way, I would be interesting in doing it.
 
He explains at 9:50. People in Microsoft just put Windbg into that specific path (C:\Debuggers) all the time, so they often design their applications to point to it, like Sysinternals Tools. So basically he's just saying, "Put everything here cause it's the default folder these applications look at." He goes on to say that the WPT doesn't have any magic folder it looks for by default.
 
Indeed we do. As to the interrupt thing, that's how interrupts work - I remember when it was explained to me years ago when I first started, and my mind was blown :). Glad to hear I am not the only one who had that reaction!
 
Yah, complete eye-opener for me! I guess now this means I need to pay especially more attention to IPIs and IRQLs now that I know better how they show up on callstacks and their affect on code flow.

Btw, Carl, do you happen to know if there's any way that interrupts like that prevent themselves from inadvertently overflowing a stack by just taking over to do its work? It would seem to me that if it's not involved with any of the original work in that thread's stack that it's less likely to ascertain whether it'll have room in the stack or not to work on its own stuff.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top