maharmstone
Investigation required, drive inaccessible after heavy usage with Emacs
Since I’ve installed emacs on my btrfs drive, and moved the .emacs.d directory there, I have noticed that sometimes the drive will just quit after a while. The drive icon still appears, Windows Performance PhysicalDisk read and writes are still measured, but there is no way to access the drive. Rarely it will recover, and after a couple hours I can access it, but mostly it requires a reboot.
Emacs opens a lot of file handles sometimes when doing async compiling. I had to limit that because even emacs couldn’t keep up with all open files. If winbtrfs allowed for mount/dismount on the go it might have helped. I think this is important, since the PC doesn’t crash there are no dumps.
Maybe this is related to #485 since I recall getting that in the early stages. But usually no error messages appear within Explorer.
P.S I’ve checked to see if any dead processes are involved, but killing them including git fsmonitor processes makes no difference. Maybe git is involved?
Update: Making drive offline & online via Disk Management seems to make it accessible again
Update: It can happen only a short time after using Emacs now. Last time it happened within a command execution (starting a REPL). I reonline’d the drive and reran the command. BSOD KMODE_EXCEPTION_NOT_HANDLED. No dump was created.
@maharmstone yesterday I got bsods twice: no_more_irp_stack_locations. I believe this is a serious issue. They happened after the drive was made inaccessible by Emacs and I offline/online’d it and continued using emacs. The first time dump creation failed, but the second time it did. Scrubbing reads zero errors.
Minidump
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
NO_MORE_IRP_STACK_LOCATIONS (35)
A higher level driver has attempted to call a lower level driver through
the IoCallDriver() interface, but there are no more stack locations in the
packet, hence, the lower level driver would not be able to access its
parameters, as there are no parameters for it. This is a disastrous
situation, since the higher level driver "thinks" it has filled in the
parameters for the lower level driver (something it MUST do before it calls
it), but since there is no stack location for the latter driver, the former
has written off of the end of the packet. This means that some other memory
has probably been trashed at this point.
Arguments:
Arg1: ffff96030a9cf4e0, Address of the IRP
Arg2: 0000000000000000
Arg3: 0000000000000000
Arg4: 0000000000000000
Debugging Details:
------------------
*** WARNING: Unable to verify timestamp for btrfs.sys
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 2780
Key : Analysis.DebugAnalysisManager
Value: Create
Key : Analysis.Elapsed.mSec
Value: 19442
Key : Analysis.Init.CPU.mSec
Value: 2687
Key : Analysis.Init.Elapsed.mSec
Value: 9723
Key : Analysis.Memory.CommitPeak.Mb
Value: 113
Key : WER.OS.Branch
Value: vb_release
Key : WER.OS.Timestamp
Value: 2019-12-06T14:06:00Z
Key : WER.OS.Version
Value: 10.0.19041.1
FILE_IN_CAB: 072422-11828-01.dmp
BUGCHECK_CODE: 35
BUGCHECK_P1: ffff96030a9cf4e0
BUGCHECK_P2: 0
BUGCHECK_P3: 0
BUGCHECK_P4: 0
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXPNP: 1 (!blackboxpnp)
BLACKBOXWINLOGON: 1
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: emacs.exe
STACK_TEXT:
ffffbf09`c7f960f8 fffff803`09c3ec96 : 00000000`00000035 ffff9603`0a9cf4e0 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
ffffbf09`c7f96100 fffff803`1a3d4bb0 : 00000000`00000000 ffff9602`00000000 ffffbf09`c7f96419 ffff9603`0a9cf5b0 : nt!IofCallDriver+0x1af516
ffffbf09`c7f96140 00000000`00000000 : ffff9602`00000000 ffffbf09`c7f96419 ffff9603`0a9cf5b0 00000000`00000000 : btrfs+0x54bb0
SYMBOL_NAME: btrfs+54bb0
MODULE_NAME: btrfs
IMAGE_NAME: btrfs.sys
STACK_COMMAND: .cxr; .ecxr ; kb
BUCKET_ID_FUNC_OFFSET: 54bb0
FAILURE_BUCKET_ID: 0x35_btrfs!unknown_function
OS_VERSION: 10.0.19041.1
BUILDLAB_STR: vb_release
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {5c63dda0-f7ca-2ee5-ebe5-e6cf30829a69}
Followup: MachineOwner
---------
Full dump gives more info:
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
NO_MORE_IRP_STACK_LOCATIONS (35)
A higher level driver has attempted to call a lower level driver through
the IoCallDriver() interface, but there are no more stack locations in the
packet, hence, the lower level driver would not be able to access its
parameters, as there are no parameters for it. This is a disastrous
situation, since the higher level driver "thinks" it has filled in the
parameters for the lower level driver (something it MUST do before it calls
it), but since there is no stack location for the latter driver, the former
has written off of the end of the packet. This means that some other memory
has probably been trashed at this point.
Arguments:
Arg1: ffff96030a9cf4e0, Address of the IRP
Arg2: 0000000000000000
Arg3: 0000000000000000
Arg4: 0000000000000000
Debugging Details:
------------------
Unable to load image \SystemRoot\system32\DRIVERS\btrfs.sys, Win32 error 0n2
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 3281
Key : Analysis.DebugAnalysisManager
Value: Create
Key : Analysis.Elapsed.mSec
Value: 5770
Key : Analysis.Init.CPU.mSec
Value: 1890
Key : Analysis.Init.Elapsed.mSec
Value: 7945
Key : Analysis.Memory.CommitPeak.Mb
Value: 116
Key : WER.OS.Branch
Value: vb_release
Key : WER.OS.Timestamp
Value: 2019-12-06T14:06:00Z
Key : WER.OS.Version
Value: 10.0.19041.1
FILE_IN_CAB: MEMORY.DMP
BUGCHECK_CODE: 35
BUGCHECK_P1: ffff96030a9cf4e0
BUGCHECK_P2: 0
BUGCHECK_P3: 0
BUGCHECK_P4: 0
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXPNP: 1 (!blackboxpnp)
BLACKBOXWINLOGON: 1
PROCESS_NAME: emacs.exe
TRAP_FRAME: ffffbf09c7f96a70 -- (.trap 0xffffbf09c7f96a70)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=00007ffe9fa5ff00 rbx=0000000000000000 rcx=0000000000005a4d
rdx=00007ffe9fa60000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80309a24af5 rsp=ffffbf09c7f96c08 rbp=fffff80309f7fa01
r8=0000000000000000 r9=ffffbf09c7f96c48 r10=0000000000000000
r11=ffff9603028ece20 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
nt!RtlImageNtHeaderEx+0x35:
fffff803`09a24af5 66390a cmp word ptr [rdx],cx ds:00007ffe`9fa60000=????
Resetting default scope
STACK_TEXT:
ffffbf09`c7f960f8 fffff803`09c3ec96 : 00000000`00000035 ffff9603`0a9cf4e0 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
ffffbf09`c7f96100 fffff803`1a3d4bb0 : 00000000`00000000 ffff9602`00000000 ffffbf09`c7f96419 ffff9603`0a9cf5b0 : nt!IofCallDriver+0x1af516
ffffbf09`c7f96140 fffff803`1a3d8795 : ffff9602`f343c180 00000066`f8dd7000 ffffd68a`0000c000 00000000`00000000 : btrfs+0x54bb0
ffffbf09`c7f96370 fffff803`1a3d1354 : ffffd68a`f65b3790 ffffe701`49f0b000 00000000`00000000 00000000`00000000 : btrfs+0x58795
ffffbf09`c7f96470 fffff803`1a3d165f : ffff9603`014892d8 ffff9603`01489010 00000000`00060043 00000000`00000000 : btrfs+0x51354
ffffbf09`c7f96540 fffff803`09a8f7d5 : 00000000`00000000 ffff9603`0787d9b0 00000000`00000000 ffff9603`01489010 : btrfs+0x5165f
ffffbf09`c7f965b0 fffff803`0cf26c5f : ffffbf09`c7f96a70 80000005`00000001 9602fe2d`a9a00430 00000000`00000000 : nt!IofCallDriver+0x55
ffffbf09`c7f965f0 fffff803`0cf24673 : ffffbf09`c7f96680 ffff9602`f3439990 00000000`00000001 ffff9602`f1004ac0 : FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x28f
ffffbf09`c7f96660 fffff803`09a8f7d5 : ffff9603`01489010 00000000`00000001 ffff9603`01489030 00000000`00000000 : FLTMGR!FltpDispatch+0xa3
ffffbf09`c7f966c0 fffff803`09a27d27 : 00000000`00000001 ffff9603`01489010 ffff9603`00311400 ffff9602`fe866c30 : nt!IofCallDriver+0x55
ffffbf09`c7f96700 fffff803`09a5deda : 00000000`00000000 ffffac2f`8664e000 ffff9603`00311410 ffff9603`003113d0 : nt!IoPageReadEx+0x1d7
ffffbf09`c7f96770 fffff803`09a5b9dd : 00000000`00000003 ffffbf09`c7f96850 ffffbf09`c7f969c8 00000000`00000000 : nt!MiIssueHardFaultIo+0xb6
ffffbf09`c7f967c0 fffff803`09a9f4d8 : 00000000`c0033333 00000000`00000000 00007ffe`9fa60000 ffffd68a`f5f578e0 : nt!MiIssueHardFault+0x29d
ffffbf09`c7f968d0 fffff803`09c0525e : ffff9602`fffed750 fffff803`09a07d6b ffff9602`fffed040 ffff9602`f77921c8 : nt!MmAccessFault+0x468
ffffbf09`c7f96a70 fffff803`09a24af5 : fffff803`09a24aae 00000000`00000000 00000000`00000001 ffffd68a`f31aed80 : nt!KiPageFault+0x35e
ffffbf09`c7f96c08 fffff803`09a24aae : 00000000`00000000 00000000`00000001 ffffd68a`f31aed80 00000000`00000000 : nt!RtlImageNtHeaderEx+0x35
ffffbf09`c7f96c10 fffff803`09e03bd8 : 00000000`00000000 00000000`00000000 00000000`00000001 00000000`00000001 : nt!RtlImageNtHeader+0x1e
ffffbf09`c7f96c40 fffff803`09f7fc79 : ffff9602`fe494080 fffff803`09f7fa01 ffff9602`fe494080 ffffbf09`c7f96ee0 : nt!EtwpEnumerateAddressSpace+0x274
ffffbf09`c7f96df0 fffff803`09e9809b : ffff9602`fbf062c0 fffff803`09f7fa80 ffff9602`fe494080 ffffbf09`c7f97018 : nt!EtwpProcessEnumCallback+0x1f9
ffffbf09`c7f96e90 fffff803`09f7fa28 : 00000000`00002000 ffffbf09`c7f96f30 ffffbf09`c7f97018 ffff9603`00000000 : nt!PsEnumProcesses+0x37
ffffbf09`c7f96ec0 fffff803`09f7f814 : 00000000`00000000 ffffbf09`c7f97018 00000000`00000001 ffff9603`00a5b500 : nt!EtwpProcessThreadImageRundown+0xc0
ffffbf09`c7f96f50 fffff803`09f7f65d : ffffbf09`c7f970a0 00000000`00000000 00000000`00000008 ffff9603`00a5b7c0 : nt!EtwpKernelTraceRundown+0x98
ffffbf09`c7f96fc0 fffff803`09f7f40f : 27a408e6`449f6c82 44e68b61`fcf23a83 ffff9603`00a5b500 00000000`00000005 : nt!EtwpUpdateGroupMasks+0x22d
ffffbf09`c7f97080 fffff803`09ec84ed : 00000000`00000008 ffff9602`00000000 ffffd68a`e5867300 00000000`00000008 : nt!EtwpUpdateLoggerGroupMasks+0x73
ffffbf09`c7f970e0 fffff803`09f9d505 : ffffd68b`11cbfaa0 ffffd68b`11cbfb54 ffffd68b`11cbfaa0 00000000`00000000 : nt!EtwpStartLogger+0xad9
ffffbf09`c7f97250 fffff803`09f9c86d : fffff803`09fcd5a0 ffffd68b`099dd730 00000000`000000c0 fffff803`09fcd5a0 : nt!EtwStartAutoLogger+0x9f5
ffffbf09`c7f97a00 fffff803`09f9d8b4 : 00000000`00000007 fffff803`09f9d790 ffff9602`e6c8acf0 ffff9602`e6c8acf0 : nt!PerfDiagpStartPerfDiagLogger+0xdd
ffffbf09`c7f97a30 fffff803`09ab85f5 : ffff9602`00000000 ffff9602`fffed040 ffff9602`e6c8acf0 ffff9602`00000000 : nt!PerfDiagpProxyWorker+0x124
ffffbf09`c7f97a70 fffff803`09b55935 : ffff9602`fffed040 00000000`00000080 ffff9602`e6ca2100 ffff9602`0000001b : nt!ExpWorkerThread+0x105
ffffbf09`c7f97b10 fffff803`09bfe728 : ffffe701`40380180 ffff9602`fffed040 fffff803`09b558e0 ffff9602`fa6571f0 : nt!PspSystemThreadStartup+0x55
ffffbf09`c7f97b60 00000000`00000000 : ffffbf09`c7f98000 ffffbf09`c7f91000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x28
SYMBOL_NAME: btrfs+54bb0
MODULE_NAME: btrfs
IMAGE_NAME: btrfs.sys
STACK_COMMAND: .cxr; .ecxr ; kb
BUCKET_ID_FUNC_OFFSET: 54bb0
FAILURE_BUCKET_ID: 0x35_btrfs!unknown_function
OS_VERSION: 10.0.19041.1
BUILDLAB_STR: vb_release
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {5c63dda0-f7ca-2ee5-ebe5-e6cf30829a69}
Followup: MachineOwner
---------
I think I've got a similar issue, writing to the drive for a while (like downloading a file) will cause it to become inaccessible. Anything that tries to access the drive or get information about it immediately freezes up the application, but a reboot fixes it and this isn't present while doing the same thing in Linux. Have you had any luck finding a solution?
Additionally, the system needs to be hard reset, as trying to reboot through Windows causes it to hang at "Waiting for the SENS" or something similar.
hang at "Waiting for the SENS"
Try if running this command both as and not as Admin (Run As Admin) works:
shutdown /r /f /t 0
