Debugging temporal hangs

I have a generic question as to what approach you’d use to debug a temporal hang, e.g. sometimes some winapi seems to be taking too long to execute and you want to get to the root of it.

If it was a regular/permanent hang, I’d kick off kd and take my time, but… given the temporal nature of the former example, what is the best course of action?

What tool would you use for creating kernel mode dumps?

This is in an app you own or some other app? Is the app talking to a driver?

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@windbg…

I have a generic question as to what approach you’d use to debug a temporal
hang, e.g. sometimes some winapi seems to be taking too long to execute and
you want to get to the root of it.

If it was a regular/permanent hang, I’d kick off kd and take my time, but…
given the temporal nature of the former example, what is the best course of
action?

What tool would you use for creating kernel mode dumps?

It’s another app, I don’t own it. In fact - it’s the Java JRE I need to debug, as the latest build seems to have introduced a regression that’s causing random slowness when performing ssl handshakes.

And yes, I assume that this is caused by talking to a network driver, but i’m still figuring out what’s the best course of action to debugging such a thing…

Come on, folks… there must be some general-purpose approach that could do :slight_smile:

There’s no one answer. You can use ProcDump to get a process dump when you
experience the hang:

https://technet.microsoft.com/en-us/sysinternals/dd996900.aspx

Though that isn’t necessarily going to tell you much. If you have a kernel
debugger attached you can break in and look at threads during the hang, but
that won’t necessarily tell you much either.

Given that it’s a hang talking about the network, I’d start with WireShark
and compare traces from the old working version to the new not working
version. This might give you a breadcrumb to work with.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@windbg…

Come on, folks… there must be some general-purpose approach that could do
:slight_smile:

There is a bit of a learning curve involved but stackwalking xperf is super
powerful for this type of thing.

https://blogs.msdn.microsoft.com/ntdebugging/tag/xperf/
https://randomascii.wordpress.com/2012/05/05/xperf-wait-analysisfinding-idle-time/

Tom

On Wed, Sep 14, 2016 at 5:37 PM, Scott Noone wrote:

> There’s no one answer. You can use ProcDump to get a process dump when you
> experience the hang:
>
> https://technet.microsoft.com/en-us/sysinternals/dd996900.aspx
>
> Though that isn’t necessarily going to tell you much. If you have a kernel
> debugger attached you can break in and look at threads during the hang, but
> that won’t necessarily tell you much either.
>
> Given that it’s a hang talking about the network, I’d start with WireShark
> and compare traces from the old working version to the new not working
> version. This might give you a breadcrumb to work with.
>
> -scott
> OSR
> @OSRDrivers
>
> wrote in message news:xxxxx@windbg…
>
>
> Come on, folks… there must be some general-purpose approach that could do
> :slight_smile:
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>