Creating the dump file is simple. Just go to the task manager, right click on the hung process, and pick "Create dump". (This works on Windows Vista and 7, not sure about 8). I'm going to assume you're running a 64 bit OS.
Getting the analysis of the resulting dump is the more complicated part. You first need to install the Debugging Tools for Windows.
http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx
Run the x64 version of WinDBG. Go to File->Open a Crash Dump and select the dump file you created.
You'll see something like:
wow64cpu!CpupSyscallStub+0x9:
00000000`73152e09 c3 ret
and a prompt waiting for you to input something. The "wow64cpu" is an indicator that you're debugging a 32 bit application and will get nonsensical data unless you switch modes. So enter the following command:
!wow64exts.sw
The next command is kind of a whopper:
~*k
This dumps the call stacks for every thread in the application. You'll see all sorts of stuff. Most of them will have "WaitForSingleObject" or some sort of "Wait" at the top - this is normal and means the thread is gracefully waiting for a signal to do something. The suspicious thread looks like this:
0207f91c 72a07ec3 ntdll_76eb0000!RtlLeaveCriticalSection+0xd
0207f984 74bb7423 mswsock!WSPGetSockOpt+0x97a
0207fc5c 72e33702 ws2_32!getsockopt+0x159
WARNING: Stack unwind information not available. Following frames may be wrong.
0207fc80 72e357a0 CoreFoundation!CFSetCreateMutableCopy+0x2f4
0207fd8c 76ee389a CoreFoundation!CFSocketGetDefaultNameRegistryPortNumber+0x9f8
0207fe9c 76ee9ec5 ntdll_76eb0000!RtlpFreeHeap+0xb7a
0207feb4 00000000 ntdll_76eb0000!_RtlUserThreadStart+0x1b
I see the same "CreateMutableCopy" function in the snapshots I took of ATH and AppleMobileDeviceService while they were eating CPU. It could be executing this in a tight loop - it's hard to say what's going on really, I don't have their sources.