An ETW trace would be ideal. If you use UIforETW with all of its default settings then it will record to circular memory buffers. Leave it constantly tracing (this has low overhead, although it does reserve a few hundred MB of RAM) and wait for the hang. As soon as possible *after* Chrome has recovered from the hang is the ideal time to record the trace as it will have information about the threads that resumed running when Chrome started running again, as well as having details about applications that weren't pumping messages.

I am adding few labels to track this issue, please feel free to update them if required.

Thanks, I'll try to grab an ETW trace as soon as the problem repro. Last time I've tried to grab one there was a lot of missing events from it, hopefully I'll be more lucky this time.

Grabbing a trace on this machine is pretty slow, it can take 10-15 between the time I hit save and when WPA open with my trace loaded... (and it really stress the CPU during this time)

It is *possible* that you are hitting the same bug that I just reported:

 crbug.com/667820 

The length of the hangs seems suspiciously similar, and in the case of that bug it was network related.

Theonly way to know for sure is to record an ETW trace or equivalent. You should be able to leave UIforETW running in continuous mode (Circular buffer tracing) on your home machine. Then, when you next encounter this issue type Ctrl+Win+C. For fastest results you should make sure that Settings->Chrome developer is *not* checked. And, don't bother loading the trace into WPA on your home machine - that is best done on a beefy workstation.

You may be able to avoid missing events by unchecking CPU sampling call stacks, although there is the risk that those events might be crucial. Do *not* uncheck Context switch call stacks.

I still haven't been able to grab an ETW trace (my computer seems way to slow for this apparently), but I've switched to using a wired connection (and disabled my Wifi adapter) and the problem is gone, so I guess that it's a driver issue... My Wifi card is a DWA-552, and the latest available driver is from 08/31/10, so I'm probably due for a new Wifi adapter (or I'll stay with the ethernet connection).

That's a pity. It does sound like it is a driver issue, or possibly the 667820 bug I mentioned above, which is socket related and could therefore be Wifi related.