I did as you said, and directly after logging on with verifier active, I receive a BSOD.
Unfortunately, there is an issue with the .dmp files. They won't compress, and they seem to have dissapeared from c/windows/minidump after being copied. They are also not being picked up by the automatic debug program that is recommended by the site.
I can still open it with WinDBG though, and this was the result:
Microsoft (R) Windows Debugger Version 6.3.9600.17298 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\Daniel\Desktop\Latest Dump\021515-23041-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred SRV*C:\Windows\symbol_cache*
http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*C:\Windows\symbol_cache*
http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.18717.amd64fre.win7sp1_gdr.150113-1808
Machine Name:
Kernel base = 0xfffff800`02c57000 PsLoadedModuleList = 0xfffff800`02e9b890
Debug session time: Sun Feb 15 21:21:57.747 2015 (UTC + 9:30)
System Uptime: 0 days 0:01:05.980
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 C4, {40, 0, fffff980059fec50, 0}
*** WARNING: Unable to verify timestamp for ndisrd.sys
*** ERROR: Module load completed but symbols could not be loaded for ndisrd.sys
Probably caused by : ndisrd.sys ( ndisrd+2716 )
Followup: MachineOwner
---------
3: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
be among the most commonly seen crashes.
Arguments:
Arg1: 0000000000000040, Acquiring a spinlock at IRQL < DISPATCH_LEVEL.
Arg2: 0000000000000000, Current IRQL
Arg3: fffff980059fec50, Spinlock address
Arg4: 0000000000000000
Debugging Details:
------------------
BUGCHECK_STR: 0xc4_40
CURRENT_IRQL: 0
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VERIFIER_ENABLED_VISTA_MINIDUMP
PROCESS_NAME: NetSvcHelp.exe
ANALYSIS_VERSION: 6.3.9600.17298 (debuggers(dbg).141024-1500) x86fre
LAST_CONTROL_TRANSFER: from fffff8000315b4ec to fffff80002ccbec0
STACK_TEXT:
fffff880`0abbd688 fffff800`0315b4ec : 00000000`000000c4 00000000`00000040 00000000`00000000 fffff980`059fec50 : nt!KeBugCheckEx
fffff880`0abbd690 fffff800`0316c2df : 00000000`00000002 fffffa80`0c6d6dc8 00000000`00000000 fffff800`031696bb : nt!VerifierBugCheckIfAppropriate+0x3c
fffff880`0abbd6d0 fffff880`03f49716 : fffffa80`10c955c0 fffff980`059fec00 fffff980`16d5efb0 fffff880`0abbd798 : nt!VerifierKeAcquireSpinLockAtDpcLevel+0xa0
fffff880`0abbd730 fffffa80`10c955c0 : fffff980`059fec00 fffff980`16d5efb0 fffff880`0abbd798 00000000`00000000 : ndisrd+0x2716
fffff880`0abbd738 fffff980`059fec00 : fffff980`16d5efb0 fffff880`0abbd798 00000000`00000000 fffff880`03f4ab99 : 0xfffffa80`10c955c0
fffff880`0abbd740 fffff980`16d5efb0 : fffff880`0abbd798 00000000`00000000 fffff880`03f4ab99 00000000`00010001 : 0xfffff980`059fec00
fffff880`0abbd748 fffff880`0abbd798 : 00000000`00000000 fffff880`03f4ab99 00000000`00010001 fffff980`16d6aff0 : 0xfffff980`16d5efb0
fffff880`0abbd750 00000000`00000000 : fffff880`03f4ab99 00000000`00010001 fffff980`16d6aff0 00000000`00000000 : 0xfffff880`0abbd798
STACK_COMMAND: kb
FOLLOWUP_IP:
ndisrd+2716
fffff880`03f49716 ?? ???
SYMBOL_STACK_INDEX: 3
SYMBOL_NAME: ndisrd+2716
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: ndisrd
IMAGE_NAME: ndisrd.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4fc6df85
FAILURE_BUCKET_ID: X64_0xc4_40_VRF_ndisrd+2716
BUCKET_ID: X64_0xc4_40_VRF_ndisrd+2716
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:x64_0xc4_40_vrf_ndisrd+2716
FAILURE_ID_HASH: {30bca9d7-111a-da6d-af09-4e1e9b7679e4}
Followup: MachineOwner
---------
I am going to attempt to obtain a .dmp file to upload by running the verifier again.