Using WinDbg Episode 1 - Solve a real-world high CPU issue on an Active Directory Domain Controller

[@lochlanspeck]

Highly enjoyable - would def like to see more videos like this, where one learns not only about debugging, but also a lot about how Windows is "put together". Thanks Ryan!

[@ryanries09]

Thank you, glad you found it useful!

[@habeebcharm8432]

Hi You have saved my day at work in finding the root cause of my issue through User Dumps... Kudos to your work and continue the same ... Thank u so much...

[@ryanries09]

Nice, glad it was helpful, thanks for watching!

[@ianmartineau4661]

First time watching a debugging session. Very nice knowledge gain for an admin. Will continue watching the other episodes. Thanks.

[@jasonbender2748]

As soon as you ran !us for lsass I saw the getDC call and dns client call. Why would we need to go off box if we are a DC unless we didn’t find what we were looking for. Being KDC stack I figured it was either bad password being forwarded up to PDC for password verification or the winRM group call failed.

[@ryanries09]

Bingo. We went searching our trusted domains only because we didn't find the group locally. You're right. :)

[@CH33S3BALL4U]

Good vod Ryan

[@ryanries09]

Thanks for watching Joe!

[@Lucas-dq9wf]

I really like this serie ! Thanks ! I have a question: Is there a way for us to determine what name the DNSAPI!DnsQuery tries to resolve ? Is this possible without private symbols ? timecode: 1:05:41

[@ryanries09]

Yes, it would have been a lot more obvious with private symbols, but even with public symbols and a little bit of creativity and power of inference you can search the contents of those CPU registers at the stack frames where we're doing the DNS query -- it was the DNS name for one of the trusted domains. Because the DC was searching its trusted domains for that security group since the security group didn't exist in the local domain. I had to sort of skim around it though, I couldn't actually show the DNS name because I couldn't let you see it.

[@thehouse2620]

very useful for getting to know windbg preview. i took notes and plan to try some of these commands on our own 3rd party software. Is there anyway to see how much time threads were taking to complete?

[@SemeshkoV]

How did you go about resolving or handling the suspected malware issue?

[@ryanries09]

Turns out it was not suspected malware, it was "legitmate" security software (Stealthbits) that could have been mistaken for malware, because it was acting like malware. Even though it wasn't malware in the end. The customer could keep using the 3rd party software as it wasn't ultimately responsible for the high CPU usage, even though I did make it known that I found the software offensive in the way it was patching internal Microsoft functions.

[@hackfans8143]

awsome video