BSOD when accessing Ramdisk via SMB share?

Started by txhxex

txhxex

BSOD when accessing Ramdisk via SMB share?   08 January 2014, 23:24

I hope I'm not blaming the wrong software here, but the BSOD only happens for the RAM Disk Drive.

My Setup:
- Windows 2012 Server
- latest RAM Disk software available on the website
- 4gb RAM as R:
- has a default admin share of \\server\R$, and a public one of \\server\RAM

Often (not always) when I access either one from another computer in the network the server bluescreens. I have programming/debugging experience if you need more details. But I'd rather not crash the server again wink

I also tried running the verifier tool from the WDK. Unfortunately then the install of the RAM disk software bluescreens already (I probably have a dump for that as well).

Here is the analyzed dump:

Microsoft (R) Windows Debugger Version 6.2.9200.16384 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\Minidump\010614-8953-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*c:\windows\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 8 Kernel Version 9200 MP (8 procs) Free x64
Product: Server, suite: TerminalServer SingleUserTS
Built by: 9200.16628.amd64fre.win8_gdr.130531-1504
Machine Name:
Kernel base = 0xfffff802`16876000 PsLoadedModuleList = 0xfffff802`16b42a20
Debug session time: Mon Jan  6 22:51:53.199 2014 (UTC - 5:00)
System Uptime: 0 days 0:03:16.955
Loading Kernel Symbols
...............................................................
................................................................
...............
Loading User Symbols
Loading unloaded module list
.......
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck C4, {2001f, fffff88001107950, 0, 0}

*** WARNING: Unable to verify timestamp for spvve.sys
*** ERROR: Module load completed but symbols could not be loaded for spvve.sys
Probably caused by : spvve.sys ( spvve+280df )

Followup: MachineOwner
---------

2: 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: 000000000002001f, ID of the 'IrqlZwPassive' rule that was violated.
Arg2: fffff88001107950, A pointer to the string describing the violated rule condition.
Arg3: 0000000000000000, An optional pointer to the rule state variable(s).
Arg4: 0000000000000000, Reserved (unused)

Debugging Details:
------------------


DV_VIOLATED_CONDITION:  ZwEnumerateKey should only be called at IRQL = PASSIVE_LEVEL.

DV_MSDN_LINK: !url http://go.microsoft.com/fwlink/?LinkId=216048

DV_RULE_INFO: !ruleinfo 0x2001f

BUGCHECK_STR:  0xc4_IrqlZwPassive_XDV

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VERIFIER_ENABLED_VISTA_MINIDUMP

PROCESS_NAME:  System

CURRENT_IRQL:  1

LAST_CONTROL_TRANSFER:  from fffff8800110521f to fffff802168d0440

STACK_TEXT:  
fffff880`02d084a8 fffff880`0110521f : 00000000`000000c4 00000000`0002001f fffff880`01107950 00000000`00000000 : nt!KeBugCheckEx
fffff880`02d084b0 fffff880`010fc395 : fffff980`39d84ee0 00000000`00000118 fffff880`02d08740 fffff880`16a8a900 : VerifierExt!SLIC_abort+0x47
fffff880`02d084f0 fffff880`010fc3d0 : 00000000`20202058 fffff880`01100665 00000000`00000081 00000000`00000118 : VerifierExt!ZwEnumerateValueKey_wrapper+0x8d
fffff880`02d08520 fffff802`16ed5278 : fffff880`16aa80df 00000000`00000000 fffff880`02d08628 ffffffff`80000db4 : VerifierExt!ZwEnumerateKey_wrapper+0x30
fffff880`02d08560 fffff880`16aa80df : ffffffff`80000db4 ffffffff`80000db4 00000000`00000000 fffff802`16ed87db : nt!VfZwEnumerateKey+0x6c
fffff880`02d085b0 ffffffff`80000db4 : ffffffff`80000db4 00000000`00000000 fffff802`16ed87db fffff880`00000118 : spvve+0x280df
fffff880`02d085b8 ffffffff`80000db4 : 00000000`00000000 fffff802`16ed87db fffff880`00000118 fffff880`02d08628 : 0xffffffff`80000db4
fffff880`02d085c0 00000000`00000000 : fffff802`16ed87db fffff880`00000118 fffff880`02d08628 fffff980`39d84ee0 : 0xffffffff`80000db4


STACK_COMMAND:  kb

FOLLOWUP_IP: 
spvve+280df
fffff880`16aa80df ??              ???

SYMBOL_STACK_INDEX:  5

SYMBOL_NAME:  spvve+280df

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: spvve

IMAGE_NAME:  spvve.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  52859da1

FAILURE_BUCKET_ID:  0xc4_IrqlZwPassive_XDV_VRF_spvve+280df

BUCKET_ID:  0xc4_IrqlZwPassive_XDV_VRF_spvve+280df

Followup: MachineOwner
---------
txhxex

Re: BSOD when accessing Ramdisk via SMB share?   08 January 2014, 23:29

Sorry, the previous dump was from the verifier tool. Here is the one from the SMB crash. There are no references to the RAM drive in the stack. But it only happens for the RAM disk share, not a regular disk share. Even other shares from WebDrive work fine.

Again, I am not 100% convinced that RAM disk has a problem here, but I not getting anywhere blaming srv2.sys for the crash.

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000000000000000, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
	bit 0 : value 0 = read operation, 1 = write operation
	bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff8003f2b1eb0, address which referenced memory

Debugging Details:
------------------


READ_ADDRESS: GetPointerFromAddress: unable to read from fffff8003f568168
GetUlongFromAddress: unable to read from fffff8003f5681f8
 0000000000000000 Nonpaged pool

CURRENT_IRQL:  2

FAULTING_IP: 
nt!IopCompleteRequest+d30
fffff800`3f2b1eb0 488b00          mov     rax,qword ptr [rax]

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT_SERVER

BUGCHECK_STR:  AV

PROCESS_NAME:  System

IRP_ADDRESS:  fffffa800ca58588

TRAP_FRAME:  fffff88019cfef40 -- (.trap 0xfffff88019cfef40)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000001 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8003f2b1eb0 rsp=fffff88019cff0d0 rbp=fffff88019cff1e8
 r8=0000000000000000  r9=0000000000000000 r10=fffff8003f508e20
r11=fffffa800eb13a10 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz ac pe cy
nt!IopCompleteRequest+0xd30:
fffff800`3f2b1eb0 488b00          mov     rax,qword ptr [rax] ds:00000000`00000000=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff8003f269769 to fffff8003f26a440

STACK_TEXT:  
fffff880`19cfedf8 fffff800`3f269769 : 00000000`0000000a 00000000`00000000 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`19cfee00 fffff800`3f267fe0 : 00000000`00000000 fffffa80`0dabbce0 fffffa80`0ca58600 fffff880`19cfef40 : nt!KiBugCheckDispatch+0x69
fffff880`19cfef40 fffff800`3f2b1eb0 : fffffa80`0eb13a10 fffffa80`0fa5cb00 fffff8a0`00003000 fffff980`20206f49 : nt!KiPageFault+0x260
fffff880`19cff0d0 fffff800`3f2df6ff : fffffa80`0ca58600 00000000`00000000 00000000`00000000 00000000`00000001 : nt!IopCompleteRequest+0xd30
fffff880`19cff1a0 fffff800`3f2e99d1 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDeliverApc+0x15f
fffff880`19cff220 fffff800`3f2d9c2c : 00000000`00000000 fffffa80`103469c0 00000000`00000000 00000000`00000000 : nt!KiApcInterrupt+0xc1
fffff880`19cff3b0 fffff880`166e6425 : fffffa80`10346960 fffff880`19cff4e0 fffffa80`0eb74c60 00000000`00000000 : nt!RtlAppendUnicodeStringToString+0x74
fffff880`19cff3e0 fffff880`166e595d : 00000000`00000000 fffff8a0`016884e0 fffffa80`11043a00 fffff8a0`101ec058 : srv2!SrvCreateFile+0x7f5
fffff880`19cffc30 fffff880`166e8a7c : fffff880`009ea101 fffffa80`0eb74950 00000000`00000001 fffffa80`0eb74950 : srv2!Smb2ExecuteCreateReal+0x19d
fffff880`19cffda0 fffff880`166e25bd : 00000000`00000000 ffff5266`7e966a29 fffff880`19cfff98 00000000`00000011 : srv2!Smb2ExecuteCreate+0x3c
fffff880`19cffde0 fffff880`166e2a64 : fffffa80`0fd6f950 fffffa80`0eb74950 fffffa80`0e512180 fffffa80`0eb74950 : srv2!Smb2ExecuteProviderCallback+0x6d
fffff880`19cffe50 fffff880`166e0180 : fffffa80`0e514880 fffffa80`0e514880 00000000`00000000 fffffa80`0eb74950 : srv2!SrvProcessPacket+0xed
fffff880`19cfff10 fffff800`3f264b67 : fffff880`19cfff01 00000000`00000000 fffffa80`0eb74960 fffff880`166e3000 : srv2!SrvProcpWorkerThreadProcessWorkItems+0x171
fffff880`19cfff80 fffff800`3f264b2d : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxSwitchKernelStackCallout+0x27
fffff880`199eb9e0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSwitchKernelStackContinue


STACK_COMMAND:  kb

FOLLOWUP_IP: 
srv2!SrvCreateFile+7f5
fffff880`166e6425 4c8b9b88000000  mov     r11,qword ptr [rbx+88h]

SYMBOL_STACK_INDEX:  7

SYMBOL_NAME:  srv2!SrvCreateFile+7f5

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: srv2

IMAGE_NAME:  srv2.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  51637dde

BUCKET_ID_FUNC_OFFSET:  7f5

FAILURE_BUCKET_ID:  AV_srv2!SrvCreateFile

BUCKET_ID:  AV_srv2!SrvCreateFile

Followup: MachineOwner
---------

Reply to this topic

Sometimes you can find a solution faster if you try the forum search, have a look at the knowledge base, or check the software user manual to see if your question has already been answered.

Our forum rules are simple:

  • Be polite.
  • Do not spam.
  • Write in English. If possible, check your spelling and grammar.

Author:

Email:

Subject

A brief and informative title for your message, approximately 4–8 words:

     

Spam prevention: please enter the following code in the input field below.

  *******   **         ********    ******    **    ** 
 **     **  **    **   **     **  **    **    **  **  
 **         **    **   **     **  **           ****   
 ********   **    **   **     **  **   ****     **    
 **     **  *********  **     **  **    **      **    
 **     **        **   **     **  **    **      **    
  *******         **   ********    ******       **    

Message: