Depends on the STOP code and parameters in parentheses. Post that info.
FWIW, here's a typical debug session. I've edited out a lot of extraneous stuff:
kd> kv
ChildEBP RetAddr Args to Child
bec628c0 80465f1b bec628dc 00000000 bec62930 nt!KiDispatchException+0x30e (FPO: [Non-Fpo]) (CONV: stdcall)
bec62928 80465ecd bec62d38 00000246 80402695 nt!CommonDispatchException+0x4d (FPO: [0,20,0]) (CONV: cdecl)
bec62934 80402695 bec6297c 85902e0c 85902da0 nt!KiUnexpectedInterruptTail+0x1f4
bec62948 8042d75b 00000004 e1e1aee8 85aa8ee8 nt!KiSwapThread+0xd5 (FPO: [EBP 0xbec6297c] [0,0,4])
bec629ec 804924a6 00000001 85a903a0 85b42020 nt!KeWaitForMultipleObjects+0x266 (FPO: [Non-Fpo]) (CONV: stdcall)
00000001 00000000 00000000 00000000 00000000 nt!ExpAllocateHandleTableEntry+0x246 (FPO: [Non-Fpo]) (CONV: stdcall)
kd> .exr bec628dc;.trap bec62930;kv
ExceptionAddress: 804505d9 (nt!NtWaitForMultipleObjects+0x00000275)
ExceptionCode: c0000005
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 42160e66
Attempt to read from address 42160e66
ErrCode = 00000000
eax=42160e1e ebx=85aa8ee8 ecx=e1e1aee8 edx=85b42008 esi=e1e1aee8 edi=00000004
eip=804505d9 esp=bec629a4 ebp=bec62d48 iopl=0 nv up ei ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282
nt!NtWaitForMultipleObjects+275:
804505d9 8b4048 mov eax,[eax+0x48] ds:0023:42160e66=????????
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr Args to Child
bec62d48 80465091 00000002 03c4fe80 00000001 nt!NtWaitForMultipleObjects+0x275 (FPO: [Non-Fpo]) (CONV: stdcall)
bec62d48 77f837b2 00000002 03c4fe80 00000001 nt!_KiSystemService+0xc4 (FPO: [0,0] TrapFrame @ bec62d64) (CONV: cdecl)
03c4fea8 77e12a00 03c4fe80 00000001 00000000 ntdll!LdrpSnapIAT+0xf4 (FPO: [Non-Fpo])
03c4ff04 77e12a77 03c4fed0 77cb41c0 0000ea60 USER32!_GetWindow+0x2 (FPO: [2,0,3])
03c4ff20 77c764ff 00000001 77cb41c0 00000000 USER32!_GetWindow+0x79 (FPO: [2,0,3])
WARNING: Stack unwind information not available. Following frames may be wrong.
03c4ff74 77c78ffd 03c4ffa0 03c4ffa4 03c4ffa8 SHLWAPI+0x64ff
03c4ffac 77c78f85 00000000 77e887dd 00000000 SHLWAPI+0x8ffd
03c4ffec 00000000 77c78f5c 00000000 00000000 SHLWAPI+0x8f85
kd>
You should view the above in a fixed-width font for readability. What we see here is that the system called WaitForMultipleObjects and crashed. Now, the second parameter to NtWaitForMultipleObjects is a list of handles. In this case, the pointer is 03c4fe80. A handle is a kernel mode object and must reside in kernel memory space. Kernel memory space is 80000000 and above. So whatever was passed into NtWaitForMultipleObjects wasn't a list of objects and the machine crashed.
In the information I've given, there's not enough information to tell where that number came from, but that would be the next step in determining the cause of the crash. Sometimes it's just not possible to go back in time from a dump file.