We can create a dump file from a running application or active driver crash using WinDbg. After the dump file is collected, it can be copied to another machine to analyze and debug the problem (with symbols ofcourse). Here is a quick trick to get both, the dump and symbols.

First, to get a dump file with all information we using dump command. The .dump command creates a user-mode or kernel-mode crash dump file.

Syntax (please refer to msdn for  more details on the options)

.dump Options FileName

.dump /?

Usage

0:000> .dump /mfht c:\Dumpfile.dmp

Creating c:\Dumpfile.dmp – mini user dump

Dump successfully written

.dump command has several options, but if we want a minidump with all information we just need to use /mfht where it saves full memory (accessible committed pages), data about handles and additional thread times for !runaway and .ttime commands.

After collecting the dump file we open it on the debugging machine using WinDbg and reload the symbols again. Then we use the .dumpcab command. The .dumpcab command creates a CAB file containing the current dump file. This is supported in both user mode and kernel mode across all platforms.

Syntax

.dumpcab [-a] CabName

Parameters

-a
Causes all currently loaded symbols to be included in the CAB file. For minidumps, all loaded images will be included as well. Use lml to determine which symbols and images are loaded.

CabName
The CAB file name, including extension. CabName can include an absolute or relative path; relative paths are relative to the directory in which the debugger was started. It is recommended that you choose the extension .cab.

Usage

0:001> .dumpcab -a c:\fulldump

Creating a cab file can take a VERY VERY long time. Ctrl-C can only interrupt the command after a file has been added to the cab.  Adding C:\Dumpfile.dmp – added  Adding c:\publicsymbols\wntdll.pdb\E06BEA155E9748BEA818E2D0DD2FED952\wntdll.pdb – added Wrote c:\downloads\fulldump

The file fulldump.cab now has the dump file and all related symbols so we can copy it to another machine, unpack, load the dumps/symbols and start a debugging session.

It is easily recognizable in process crash dumps by the processor instruction that caused this exception type (DIV or IDIV):

FAULTING_IP:
DLL!FindHighestID+278
1b2713c4 f775e4 div dword ptr [ebp-0×1c]

EXCEPTION_RECORD: ffffffff — (.exr ffffffffffffffff)
ExceptionAddress: 1b2713c4 (DLL!FindHighestID+0x00000278)
ExceptionCode: c0000094 (Integer divide-by-zero)
ExceptionFlags: 00000000
NumberParameters: 0

or

FAULTING_IP:
Application+263d8
004263d8 f7fe idiv eax,esi

EXCEPTION_RECORD: ffffffff — (.exr 0xffffffffffffffff)
ExceptionAddress: 004263d8 (Application+0x000263d8)
ExceptionCode: c0000094 (Integer divide-by-zero)
ExceptionFlags: 00000000
NumberParameters: 0

ERROR_CODE: (NTSTATUS) 0xc0000094 – {EXCEPTION} Integer division by zero.

This is a kernel mode counterpart of Divide by Zero pattern in user mode. It manifests under different bugchecks, for example:

1: kd> !analyze -v

[…]

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it’s a trap of a kind that the kernel isn’t allowed to have/catch (bound trap) or that is always instant death (double fault). The first number in the bugcheck params is the number of the trap (8 = double fault, etc) Consult an Intel x86 family manual to learn more about what these traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 00000000, EXCEPTION_DIVIDED_BY_ZERO
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

[…]

TRAP_FRAME: a8954c8c — (.trap 0xffffffffa8954c8c)
ErrCode = 00000000
eax=ffffffff ebx=00000000 ecx=00000005 edx=00000000 esi=00000000 edi=00000000
eip=975c42cd esp=a8954d00 ebp=a8954d4c iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
win32k!NtGdiEnumObjects+0xc6:
975c42cd f7f6 div eax,esi
Resetting default scope

PROCESS_NAME: Application.EXE

[…]

STACK_TEXT:
a8954c2c 81ac2b76 0000007f 5317512a 975c42cd nt!KeBugCheck+0x14
a8954c80 81899808 a8954c8c a8954d4c 975c42cd nt!Ki386CheckDivideByZeroTrap+0×44
a8954c80 975c42cd a8954c8c a8954d4c 975c42cd nt!KiTrap00+0×88
a8954d4c 81898a7a 062102ce 00000001 00000000 Driver!EnumObjects+0xc6
a8954d4c 77a59a94 062102ce 00000001 00000000 nt!KiFastCallEntry+0×12a
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012ca70 00000000 00000000 00000000 00000000 0×77a59a94

0: kd> !analyze -v

[…]

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000094, Exception code that caused the bugcheck
Arg2: fffff9600025ba6d, Address of the exception record for the exception that caused the bugcheck
Arg3: fffff8800ac361d0, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.

[…]

EXCEPTION_CODE: (NTSTATUS) 0xc0000094 – {EXCEPTION} Integer division by zero.

FAULTING_IP:
Driver!EnumObjects+e9
fffff960`0025ba6d f7f6 div eax,esi

CONTEXT: fffff8800ac361d0 — (.cxr 0xfffff8800ac361d0)
rax=00000000ffffffff rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff9600025ba6d rsp=fffff8800ac36ba0 rbp=fffff8800ac36ca0
r8=0000000000000000 r9=0000000000000000 r10=0000000005892f18
r11=fffff900c28379e0 r12=0000000000000000 r13=0000000000000002
r14=0000000000000001 r15=0000000000000000
iopl=0 nv up ei ng nz na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010286
Driver!EnumObjects+0xe9:
fffff960`0025ba6d f7f6 div eax,esi
Resetting default scope

[…]

STACK_TEXT:
fffff880`0ac36ba0 fffff800`01682993 Driver!EnumObjects+0xe9
fffff880`0ac36c20 00000000`748a1b3a nt!KiSystemServiceCopyEnd+0x13
00000000`001cdf08 00000000`00000000 0x748a1b3a