I hope so too.
btw. That manual crash msdn article does work - not sure the dump it creates would be of much use though (going beyond my level of expertise here). It creates a dump like the following - btw. I did this manually initiated crash when the system was all good and dandy so if I have a freeze and do this then maybe it will mean more. I guess the field "PROCESS_NAME" will hold the runaway process that causes the lock-up. In the case below it is coincidentally filled with "mbamservice.ex" but remember the system was working fine when I did this test - I expect mbam was just doing its thing at the time. I will now try to bring about a real freeze........
** Example of a forced memory dump using technique in
http://msdn.microsoft.com/en-us/library/ff545499(v=vs.85).aspx **
Microsoft (R) Windows Debugger Version 6.3.9600.17029 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Windows\Minidump\052214-22484-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred SRV*C:\symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*C:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 8 Kernel Version 9600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9600.17085.amd64fre.winblue_gdr.140330-1035
Machine Name:
Kernel base = 0xfffff802`81871000 PsLoadedModuleList = 0xfffff802`81b3b2d0
Debug session time: Thu May 22 16:13:39.222 2014 (UTC + 1:00)
System Uptime: 0 days 0:01:02.976
Loading Kernel Symbols
.
Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.
..............................................................
................................................................
...............................
Loading User Symbols
Loading unloaded module list
........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck E2, {0, 0, 0, 0}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
Followup: MachineOwner
---------
3: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
MANUALLY_INITIATED_CRASH (e2)
The user manually initiated this crash dump.
Arguments:
Arg1: 0000000000000000
Arg2: 0000000000000000
Arg3: 0000000000000000
Arg4: 0000000000000000
Debugging Details:
------------------
DUMP_FILE_ATTRIBUTES: 0x8
Kernel Generated Triage Dump
BUGCHECK_STR: MANUALLY_INITIATED_CRASH
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
PROCESS_NAME: mbamservice.ex
CURRENT_IRQL: a
ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) amd64fre
LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff802819c4fa0
STACK_TEXT:
ffffd001`5d7f9ea8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
STACK_COMMAND: kb
SYMBOL_NAME: ANALYSIS_INCONCLUSIVE
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Unknown_Module
IMAGE_NAME: Unknown_Image
DEBUG_FLR_IMAGE_TIMESTAMP: 0
IMAGE_VERSION:
BUCKET_ID: ZEROED_STACK
FAILURE_BUCKET_ID: ZEROED_STACK
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:zeroed_stack
FAILURE_ID_HASH: {4af92c9d-8968-8d00-06f5-868dfba32e9a}
Followup: MachineOwner