search

dokan-dev / dokany

User mode file system library for windows with FUSE Wrapper
http://dokan-dev.github.io
5.21k stars 661 forks source link

BSOD Using a lock during CreateFile #764

Closed TrabacchinLuigi closed 5 years ago

TrabacchinLuigi commented 5 years ago

Environment

Check List

Description

I'm getting a BSOD repeatedly. Before i can further investigate (i'll update windows and dokany) and report here, i've decided to post a log before just in case the bug is not reproducible after those changes. And also to ask for counseling, any advice is welcome.

Logs

analyzed_crash_dump.txt

TrabacchinLuigi commented 5 years ago

sorry i've noticed that there is two dups, the second one is with symbols loaded. In our fs we hang FileStreamOpening while the resource becomes available and after a while if the resource is still unavailable we return DokanResult.NotReady (NtStatus.DeviceNotReady) With the debugger i ofthen get caught there, maybe just because it's an hanging call. Could this be a problem ?

TrabacchinLuigi commented 5 years ago

Tried the last version of dokany, rebuilt with the new dokan.net still BSOD, but different stack trace in the minidump...

Crash dump Dokany 1.2.0.1000 ``` Microsoft (R) Windows Debugger Version 10.0.16299.15 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\Users\luigi.trabacchin\Desktop\122018-3343-01 - Copy.dmp] Mini Kernel Dump File: Only registers and stack trace are available Symbol search path is: srv* Executable search path is: Windows 10 Kernel Version 15063 MP (4 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Built by: 15063.0.amd64fre.rs2_release.170317-1834 Machine Name: Kernel base = 0xfffff803`cae14000 PsLoadedModuleList = 0xfffff803`cb163700 Debug session time: Thu Dec 20 10:50:01.451 2018 (UTC + 1:00) System Uptime: 0 days 0:35:10.930 Loading Kernel Symbols ............................................................... ................................................................ ............................ Loading User Symbols Loading unloaded module list .......... ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 50, {ffff9d81ca448002, 0, fffff803caf2a765, 0} *** WARNING: Unable to verify timestamp for dokan1.sys *** ERROR: Module load completed but symbols could not be loaded for dokan1.sys Could not read faulting driver name Probably caused by : dokan1.sys ( dokan1+11d61 ) Followup: MachineOwner --------- ************* Path validation summary ************** Response Time (ms) Location Deferred srv* OK C:\Users\luigi.trabacchin\Desktop\Nuova cartella 3: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* PAGE_FAULT_IN_NONPAGED_AREA (50) Invalid system memory was referenced. This cannot be protected by try-except. Typically the address is just plain bad or it is pointing at freed memory. Arguments: Arg1: ffff9d81ca448002, memory referenced. Arg2: 0000000000000000, value 0 = read operation, 1 = write operation. Arg3: fffff803caf2a765, If non-zero, the instruction address which referenced the bad memory address. Arg4: 0000000000000000, (reserved) Debugging Details: ------------------ *** WARNING: Unable to verify timestamp for dokan1.sys Could not read faulting driver name DUMP_CLASS: 1 DUMP_QUALIFIER: 400 BUILD_VERSION_STRING: 10.0.15063.1418 (WinBuild.160101.0800) SYSTEM_MANUFACTURER: Microsoft Corporation VIRTUAL_MACHINE: HyperV SYSTEM_PRODUCT_NAME: Virtual Machine SYSTEM_SKU: None SYSTEM_VERSION: Hyper-V UEFI Release v4.0 BIOS_VENDOR: Microsoft Corporation BIOS_VERSION: Hyper-V UEFI Release v4.0 BIOS_DATE: 08/31/2018 BASEBOARD_MANUFACTURER: Microsoft Corporation BASEBOARD_PRODUCT: Virtual Machine BASEBOARD_VERSION: Hyper-V UEFI Release v4.0 DUMP_TYPE: 2 BUGCHECK_P1: ffff9d81ca448002 BUGCHECK_P2: 0 BUGCHECK_P3: fffff803caf2a765 BUGCHECK_P4: 0 READ_ADDRESS: fffff803cb1f7358: Unable to get MiVisibleState Unable to get NonPagedPoolStart Unable to get NonPagedPoolEnd Unable to get PagedPoolStart Unable to get PagedPoolEnd ffff9d81ca448002 FAULTING_IP: nt!IoGetOplockKeyContextEx+15 fffff803`caf2a765 f6400203 test byte ptr [rax+2],3 MM_INTERNAL_CODE: 0 CPU_COUNT: 4 CPU_MHZ: a20 CPU_VENDOR: GenuineIntel CPU_FAMILY: 6 CPU_MODEL: 5e CPU_STEPPING: 3 CPU_MICROCODE: 6,5e,3,0 (F,M,S,R) SIG: FFFFFFFF'00000000 (cache) FFFFFFFF'00000000 (init) DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT BUGCHECK_STR: AV PROCESS_NAME: sihost.exe CURRENT_IRQL: 2 ANALYSIS_SESSION_HOST: NB10-TRABACCHIN ANALYSIS_SESSION_TIME: 12-20-2018 11:04:39.0406 ANALYSIS_VERSION: 10.0.16299.15 amd64fre TRAP_FRAME: ffff9d81c83c2d90 -- (.trap 0xffff9d81c83c2d90) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=ffff9d81ca448000 rbx=0000000000000000 rcx=0000000000000006 rdx=ffff9d81ca448000 rsi=0000000000000000 rdi=0000000000000000 rip=fffff803caf2a765 rsp=ffff9d81c83c2f20 rbp=ffffc58c4675cef0 r8=0000000000000000 r9=0000000000010000 r10=0000000000000000 r11=0000000000013000 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei ng nz na po nc nt!IoGetOplockKeyContextEx+0x15: fffff803`caf2a765 f6400203 test byte ptr [rax+2],3 ds:ffff9d81`ca448002=?? Resetting default scope LAST_CONTROL_TRANSFER: from fffff803caeb049f to fffff803caf94500 STACK_TEXT: ffff9d81`c83c2a38 fffff803`caeb049f : 00000000`00000050 ffff9d81`ca448002 00000000`00000000 ffff9d81`c83c2d90 : nt!KeBugCheckEx ffff9d81`c83c2a40 fffff803`caebc358 : 00000010`4308a600 ffffffff`00020019 00000005`0000000c 00000000`00000000 : nt!MiSystemFault+0x15df ffff9d81`c83c2b90 fffff803`cafa18da : ffffb485`324cf8e4 00000000`00000016 ffff9d81`c83c32a0 fffff803`cb3432b7 : nt!MmAccessFault+0x228 ffff9d81`c83c2d90 fffff803`caf2a765 : 00000000`30000000 00000000`00000000 ffff9d81`c7f82460 fffff803`cb099120 : nt!KiPageFault+0x31a ffff9d81`c83c2f20 fffff803`caf2a4eb : 00000000`00000000 ffff9d81`c83c2f71 ffff9d81`c83c2f7a fffff803`caea9a4c : nt!IoGetOplockKeyContextEx+0x15 ffff9d81`c83c2f50 fffff803`caf28fc5 : ffffb485`35f34ea0 00000000`00000008 00000000`00000000 ffffb485`403df140 : nt!FsRtlpOplockKeysEqual+0x5f ffff9d81`c83c2f80 fffff803`cb33a415 : 00000000`00000600 ffffc58c`430c9ca0 00000000`30000000 ffffc58c`00010000 : nt!FsRtlpRequestShareableOplock+0x50d ffff9d81`c83c3030 fffff803`cb33a144 : ffffc58c`4324ba60 ffffb485`403df140 ffffc58c`00000003 00000000`00000000 : nt!FsRtlpOplockFsctrlInternal+0x2a9 ffff9d81`c83c30d0 fffff809`b69f1d61 : 00000000`00000000 00000000`00000008 ffffc58c`00000002 ffffc58c`45b6d758 : nt!FsRtlOplockFsctrl+0x14 ffff9d81`c83c3110 00000000`00000000 : 00000000`00000008 ffffc58c`00000002 ffffc58c`45b6d758 00000000`00000000 : dokan1!__scrt_is_nonwritable_in_current_image$filt$0+0xa56 THREAD_SHA1_HASH_MOD_FUNC: b06330cd5b77977eaf374f6282ca096af4352466 THREAD_SHA1_HASH_MOD_FUNC_OFFSET: a1069dfe77e39e2d156f6bbc13d7e0b6d7dbf3b1 THREAD_SHA1_HASH_MOD: fc75af73830548e7c63f81c5e385ac22382a9750 FOLLOWUP_IP: dokan1!__scrt_is_nonwritable_in_current_image$filt$0+a56 fffff809`b69f1d61 8bd8 mov ebx,eax FAULT_INSTR_CODE: 4489d88b SYMBOL_STACK_INDEX: 9 SYMBOL_NAME: dokan1!__scrt_is_nonwritable_in_current_image$filt$0+a56 FOLLOWUP_NAME: MachineOwner MODULE_NAME: dokan1 IMAGE_NAME: dokan1.sys DEBUG_FLR_IMAGE_TIMESTAMP: 5b6c3d88 STACK_COMMAND: .thread ; .cxr ; kb BUCKET_ID_FUNC_OFFSET: a56 FAILURE_BUCKET_ID: AV_R_INVALID_dokan1!__scrt_is_nonwritable_in_current_image$filt$0 BUCKET_ID: AV_R_INVALID_dokan1!__scrt_is_nonwritable_in_current_image$filt$0 PRIMARY_PROBLEM_CLASS: AV_R_INVALID_dokan1!__scrt_is_nonwritable_in_current_image$filt$0 TARGET_TIME: 2018-12-20T09:50:01.000Z OSBUILD: 15063 OSSERVICEPACK: 1418 SERVICEPACK_NUMBER: 0 OS_REVISION: 0 SUITE_MASK: 272 PRODUCT_TYPE: 1 OSPLATFORM_TYPE: x64 OSNAME: Windows 10 OSEDITION: Windows 10 WinNt TerminalServer SingleUserTS OS_LOCALE: USER_LCID: 0 OSBUILD_TIMESTAMP: 2018-10-10 09:19:30 BUILDDATESTAMP_STR: 160101.0800 BUILDLAB_STR: WinBuild BUILDOSVER_STR: 10.0.15063.1418 ANALYSIS_SESSION_ELAPSED_TIME: 1c41 ANALYSIS_SOURCE: KM FAILURE_ID_HASH_STRING: km:av_r_invalid_dokan1!__scrt_is_nonwritable_in_current_image$filt$0 FAILURE_ID_HASH: {0d52f469-aa51-8f49-f9bd-c3973f7a2d0e} Followup: MachineOwner --------- ```
TrabacchinLuigi commented 5 years ago

It seems to me that the stack trace changes every time...

Crash dump Dokany 1.2.0.1000 ``` 1: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* UNEXPECTED_KERNEL_MODE_TRAP (7f) This means a trap occurred in kernel mode, and it's a trap of a kind that the kernel isn't allowed to have/catch (bound trap) or that is always instant death (double fault). The first number in the bugcheck params is the number of the trap (8 = double fault, etc) Consult an Intel x86 family manual to learn more about what these traps are. Here is a *portion* of those codes: If kv shows a taskGate use .tss on the part before the colon, then kv. Else if kv shows a trapframe use .trap on that value Else .trap on the appropriate frame will show where the trap was taken (on x86, this will be the ebp that goes with the procedure KiTrap) Endif kb will then show the corrected stack. Arguments: Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT Arg2: ffffc500445c9f50 Arg3: ffffc5004ad48fa0 Arg4: fffff803b945de5c Debugging Details: ------------------ *** WARNING: Unable to verify timestamp for win32k.sys *** ERROR: Module load completed but symbols could not be loaded for win32k.sys DUMP_CLASS: 1 DUMP_QUALIFIER: 400 BUILD_VERSION_STRING: 10.0.15063.1418 (WinBuild.160101.0800) SYSTEM_MANUFACTURER: Microsoft Corporation VIRTUAL_MACHINE: HyperV SYSTEM_PRODUCT_NAME: Virtual Machine SYSTEM_SKU: None SYSTEM_VERSION: Hyper-V UEFI Release v4.0 BIOS_VENDOR: Microsoft Corporation BIOS_VERSION: Hyper-V UEFI Release v4.0 BIOS_DATE: 08/31/2018 BASEBOARD_MANUFACTURER: Microsoft Corporation BASEBOARD_PRODUCT: Virtual Machine BASEBOARD_VERSION: Hyper-V UEFI Release v4.0 DUMP_TYPE: 2 BUGCHECK_P1: 8 BUGCHECK_P2: ffffc500445c9f50 BUGCHECK_P3: ffffc5004ad48fa0 BUGCHECK_P4: fffff803b945de5c BUGCHECK_STR: 0x7f_8 TRAP_FRAME: 7d9a3a50fc9eac6e -- (.trap 0x7d9a3a50fc9eac6e) Unable to read trap frame at 7d9a3a50`fc9eac6e CPU_COUNT: 4 CPU_MHZ: a20 CPU_VENDOR: GenuineIntel CPU_FAMILY: 6 CPU_MODEL: 5e CPU_STEPPING: 3 CPU_MICROCODE: 6,5e,3,0 (F,M,S,R) SIG: FFFFFFFF'00000000 (cache) FFFFFFFF'00000000 (init) CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT PROCESS_NAME: sihost.exe CURRENT_IRQL: 0 ANALYSIS_SESSION_HOST: NB10-TRABACCHIN ANALYSIS_SESSION_TIME: 12-20-2018 12:21:16.0501 ANALYSIS_VERSION: 10.0.16299.15 amd64fre EXCEPTION_RECORD: cc482b4c50343024 -- (.exr 0xcc482b4c50343024) Cannot read Exception record @ cc482b4c50343024 LAST_CONTROL_TRANSFER: from fffff803b95908e9 to fffff803b9580500 STACK_OVERFLOW: Stack Limit: ffffc5004ad49000. Use (kF) and (!stackusage) to investigate stack usage. STACK_TEXT: ffffc500`445c9e08 fffff803`b95908e9 : 00000000`0000007f 00000000`00000008 ffffc500`445c9f50 ffffc500`4ad48fa0 : nt!KeBugCheckEx ffffc500`445c9e10 fffff803`b958c68c : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69 ffffc500`445c9f50 fffff803`b945de5c : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0x28c ffffc500`4ad48fa0 fffff803`b95909c2 : cc482b4c`50343024 7444650e`7b711c4e 7d9a3a50`fc9eac6e 5a9b19d6`4a867503 : nt!KiDispatchException+0x2c ffffc500`4ad49150 fffff803`b958b4d2 : 3725c3d4`62338a3b 1be96730`31f6bc49 c15a40fe`17b0059f ccbb7d65`8a9a88bc : nt!KiExceptionDispatch+0xc2 ffffc500`4ad49330 fffff80d`809f4ef8 : fffff80d`809fabd0 00000000`00000001 00000000`00000008 00000000`00000065 : nt!KiBreakpointTrap+0x2d2 ffffc500`4ad494c0 fffff80d`809fabd0 : 00000000`00000001 00000000`00000008 00000000`00000065 00000000`00000000 : dokan1!DokanMain+0x2b8 [e:\islog\dev\app\dokan\dokany\dokan\dokan.c @ 237] ffffc500`4ad494c8 00000000`00000001 : 00000000`00000008 00000000`00000065 00000000`00000000 fffff80d`809faf36 : dokan1!DokanNtStatusFromWin32+0xe30 [e:\islog\dev\app\dokan\dokany\dokan\ntstatus.c @ 31] ffffc500`4ad494d0 00000000`00000008 : 00000000`00000065 00000000`00000000 fffff80d`809faf36 fffff80d`809fcde8 : 0x1 ffffc500`4ad494d8 00000000`00000065 : 00000000`00000000 fffff80d`809faf36 fffff80d`809fcde8 00000000`00000010 : 0x8 ffffc500`4ad494e0 00000000`00000000 : fffff80d`809faf36 fffff80d`809fcde8 00000000`00000010 ffffc500`4ad49000 : 0x65 THREAD_SHA1_HASH_MOD_FUNC: ff7d0e340db07efd91853b005166d66ce2303bdf THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 5e0674684a0ed83df72c02d936f18d08b36e85b7 THREAD_SHA1_HASH_MOD: 128baabb2c5e56fe5ab10ecba4ca4659304fc2f6 FOLLOWUP_IP: dokan1!DokanMain+2b8 [e:\islog\dev\app\dokan\dokany\dokan\dokan.c @ 237] fffff80d`809f4ef8 8bcf mov ecx,edi FAULT_INSTR_CODE: 15ffcf8b FAULTING_SOURCE_LINE: e:\islog\dev\app\dokan\dokany\dokan\dokan.c FAULTING_SOURCE_FILE: e:\islog\dev\app\dokan\dokany\dokan\dokan.c FAULTING_SOURCE_LINE_NUMBER: 237 SYMBOL_STACK_INDEX: 6 SYMBOL_NAME: dokan1!DokanMain+2b8 FOLLOWUP_NAME: MachineOwner MODULE_NAME: dokan1 IMAGE_NAME: dokan1.sys DEBUG_FLR_IMAGE_TIMESTAMP: 5b6c3d88 STACK_COMMAND: .thread ; .cxr ; kb BUCKET_ID_FUNC_OFFSET: 2b8 FAILURE_BUCKET_ID: 0x7f_8_dokan1!DokanMain BUCKET_ID: 0x7f_8_dokan1!DokanMain PRIMARY_PROBLEM_CLASS: 0x7f_8_dokan1!DokanMain TARGET_TIME: 2018-12-20T11:01:54.000Z OSBUILD: 15063 OSSERVICEPACK: 1418 SERVICEPACK_NUMBER: 0 OS_REVISION: 0 SUITE_MASK: 272 PRODUCT_TYPE: 1 OSPLATFORM_TYPE: x64 OSNAME: Windows 10 OSEDITION: Windows 10 WinNt TerminalServer SingleUserTS OS_LOCALE: USER_LCID: 0 OSBUILD_TIMESTAMP: 2018-10-10 09:19:30 BUILDDATESTAMP_STR: 160101.0800 BUILDLAB_STR: WinBuild BUILDOSVER_STR: 10.0.15063.1418 ANALYSIS_SESSION_ELAPSED_TIME: 27205 ANALYSIS_SOURCE: KM FAILURE_ID_HASH_STRING: km:0x7f_8_dokan1!dokanmain FAILURE_ID_HASH: {f34a891e-6a0e-ce29-ec83-91bfccf47628} Followup: MachineOwner --------- ```
TrabacchinLuigi commented 5 years ago

I've updated windows to last version, same result i'll attach the analyzed dump anyway. Thi time the stack trace is the same of one of the previous...

Crash dump Dokany 1.2.0.1000 ``` Microsoft (R) Windows Debugger Version 10.0.16299.15 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\Users\luigi.trabacchin\Desktop\122018-10843-01.dmp] Mini Kernel Dump File: Only registers and stack trace are available Symbol search path is: srv* Executable search path is: Windows 10 Kernel Version 17134 MP (4 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Built by: 17134.1.amd64fre.rs4_release.180410-1804 Machine Name: Kernel base = 0xfffff801`16e8f000 PsLoadedModuleList = 0xfffff801`1723d150 Debug session time: Thu Dec 20 17:39:56.977 2018 (UTC + 1:00) System Uptime: 0 days 0:02:20.721 Loading Kernel Symbols ............................................................... ................................................................ .............................. Loading User Symbols Loading unloaded module list ........ ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 7F, {8, fffff8011906fe50, ffff8b0a7c150f60, fffff80116f4f44c} *** ERROR: Module load completed but symbols could not be loaded for dokan1.sys Probably caused by : dokan1.sys ( dokan1+4ef8 ) Followup: MachineOwner --------- ************* Path validation summary ************** Response Time (ms) Location Deferred srv* OK C:\Users\luigi.trabacchin\Desktop\Nuova cartella 0: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* UNEXPECTED_KERNEL_MODE_TRAP (7f) This means a trap occurred in kernel mode, and it's a trap of a kind that the kernel isn't allowed to have/catch (bound trap) or that is always instant death (double fault). The first number in the bugcheck params is the number of the trap (8 = double fault, etc) Consult an Intel x86 family manual to learn more about what these traps are. Here is a *portion* of those codes: If kv shows a taskGate use .tss on the part before the colon, then kv. Else if kv shows a trapframe use .trap on that value Else .trap on the appropriate frame will show where the trap was taken (on x86, this will be the ebp that goes with the procedure KiTrap) Endif kb will then show the corrected stack. Arguments: Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT Arg2: fffff8011906fe50 Arg3: ffff8b0a7c150f60 Arg4: fffff80116f4f44c Debugging Details: ------------------ DUMP_CLASS: 1 DUMP_QUALIFIER: 400 BUILD_VERSION_STRING: 10.0.17134.472 (WinBuild.160101.0800) SYSTEM_MANUFACTURER: Microsoft Corporation VIRTUAL_MACHINE: HyperV SYSTEM_PRODUCT_NAME: Virtual Machine SYSTEM_SKU: None SYSTEM_VERSION: Hyper-V UEFI Release v4.0 BIOS_VENDOR: Microsoft Corporation BIOS_VERSION: Hyper-V UEFI Release v4.0 BIOS_DATE: 08/31/2018 BASEBOARD_MANUFACTURER: Microsoft Corporation BASEBOARD_PRODUCT: Virtual Machine BASEBOARD_VERSION: Hyper-V UEFI Release v4.0 DUMP_TYPE: 2 BUGCHECK_P1: 8 BUGCHECK_P2: fffff8011906fe50 BUGCHECK_P3: ffff8b0a7c150f60 BUGCHECK_P4: fffff80116f4f44c BUGCHECK_STR: 0x7f_8 TRAP_FRAME: ba2b2500007b9f70 -- (.trap 0xba2b2500007b9f70) Unable to read trap frame at ba2b2500`007b9f70 CPU_COUNT: 4 CPU_MHZ: a20 CPU_VENDOR: GenuineIntel CPU_FAMILY: 6 CPU_MODEL: 5e CPU_STEPPING: 3 CPU_MICROCODE: 6,5e,3,0 (F,M,S,R) SIG: FFFFFFFF'00000000 (cache) FFFFFFFF'00000000 (init) CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT PROCESS_NAME: sihost.exe CURRENT_IRQL: 0 ANALYSIS_SESSION_HOST: NB10-TRABACCHIN ANALYSIS_SESSION_TIME: 12-20-2018 18:30:13.0030 ANALYSIS_VERSION: 10.0.16299.15 amd64fre EXCEPTION_RECORD: 017d03bb9f5000bb -- (.exr 0x17d03bb9f5000bb) Cannot read Exception record @ 017d03bb9f5000bb LAST_CONTROL_TRANSFER: from fffff80117049c69 to fffff801170390a0 STACK_OVERFLOW: Stack Limit: ffff8b0a7c151000. Use (kF) and (!stackusage) to investigate stack usage. STACK_TEXT: fffff801`1906fd08 fffff801`17049c69 : 00000000`0000007f 00000000`00000008 fffff801`1906fe50 ffff8b0a`7c150f60 : nt!KeBugCheckEx fffff801`1906fd10 fffff801`1704557f : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69 fffff801`1906fe50 fffff801`16f4f44c : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0x27f ffff8b0a`7c150f60 fffff801`17049d42 : 017d03bb`9f5000bb 043bd810`027b4e70 ba2b2500`007b9f70 7c256244`94a47002 : nt!KiDispatchException+0x2c ffff8b0a`7c151110 fffff801`170443d2 : ffa00021`05e9fe02 000101f0`00210139 4905b000`20046002 000a5525`2a010a00 : nt!KiExceptionDispatch+0xc2 ffff8b0a`7c1512f0 fffff804`e4944ef8 : fffff804`e494abd0 00000000`00000001 00000000`00000008 00000000`00000065 : nt!KiBreakpointTrap+0x2d2 ffff8b0a`7c151480 fffff804`e494abd0 : 00000000`00000001 00000000`00000008 00000000`00000065 00000000`00000000 : dokan1!DokanMain+0x2b8 [e:\islog\dev\app\dokan\dokany\dokan\dokan.c @ 237] ffff8b0a`7c151488 00000000`00000001 : 00000000`00000008 00000000`00000065 00000000`00000000 fffff804`e494af36 : dokan1!DokanNtStatusFromWin32+0xe30 [e:\islog\dev\app\dokan\dokany\dokan\ntstatus.c @ 31] ffff8b0a`7c151490 00000000`00000008 : 00000000`00000065 00000000`00000000 fffff804`e494af36 fffff804`e494cde8 : 0x1 ffff8b0a`7c151498 00000000`00000065 : 00000000`00000000 fffff804`e494af36 fffff804`e494cde8 ffff8b0a`7c151b40 : 0x8 ffff8b0a`7c1514a0 00000000`00000000 : fffff804`e494af36 fffff804`e494cde8 ffff8b0a`7c151b40 ffff8b0a`7c151000 : 0x65 THREAD_SHA1_HASH_MOD_FUNC: ff7d0e340db07efd91853b005166d66ce2303bdf THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 72d9a32958ed10ec0cca37e4b70303354b2e175b THREAD_SHA1_HASH_MOD: 128baabb2c5e56fe5ab10ecba4ca4659304fc2f6 FOLLOWUP_IP: dokan1!DokanMain+2b8 [e:\islog\dev\app\dokan\dokany\dokan\dokan.c @ 237] fffff804`e4944ef8 8bcf mov ecx,edi FAULT_INSTR_CODE: 15ffcf8b FAULTING_SOURCE_LINE: e:\islog\dev\app\dokan\dokany\dokan\dokan.c FAULTING_SOURCE_FILE: e:\islog\dev\app\dokan\dokany\dokan\dokan.c FAULTING_SOURCE_LINE_NUMBER: 237 SYMBOL_STACK_INDEX: 6 SYMBOL_NAME: dokan1!DokanMain+2b8 FOLLOWUP_NAME: MachineOwner MODULE_NAME: dokan1 IMAGE_NAME: dokan1.sys DEBUG_FLR_IMAGE_TIMESTAMP: 5b6c3d88 STACK_COMMAND: .thread ; .cxr ; kb BUCKET_ID_FUNC_OFFSET: 2b8 FAILURE_BUCKET_ID: 0x7f_8_dokan1!DokanMain BUCKET_ID: 0x7f_8_dokan1!DokanMain PRIMARY_PROBLEM_CLASS: 0x7f_8_dokan1!DokanMain TARGET_TIME: 2018-12-20T16:39:56.000Z OSBUILD: 17134 OSSERVICEPACK: 472 SERVICEPACK_NUMBER: 0 OS_REVISION: 0 SUITE_MASK: 272 PRODUCT_TYPE: 1 OSPLATFORM_TYPE: x64 OSNAME: Windows 10 OSEDITION: Windows 10 WinNt TerminalServer SingleUserTS OS_LOCALE: USER_LCID: 0 OSBUILD_TIMESTAMP: 2018-12-14 07:53:05 BUILDDATESTAMP_STR: 160101.0800 BUILDLAB_STR: WinBuild BUILDOSVER_STR: 10.0.17134.472 ANALYSIS_SESSION_ELAPSED_TIME: 22ae ANALYSIS_SOURCE: KM FAILURE_ID_HASH_STRING: km:0x7f_8_dokan1!dokanmain FAILURE_ID_HASH: {f34a891e-6a0e-ce29-ec83-91bfccf47628} Followup: MachineOwner --------- ```
Liryna commented 5 years ago

Hi @TrabacchinLuigi ,

Do you think this could be reproduce with the mirror changed ?

TrabacchinLuigi commented 5 years ago

our implementation is quite similar to the mirror sample, we just might not have all the files available because it's kind of a partial network drive, if a file is not available it hangs the FileStreamOpening for few seconds with a ManualResetEvent... so yes, i guess we could add to mirror something that randomly hang the same method and see what happens...

TrabacchinLuigi commented 5 years ago

Sorry i've posted some methods specific to our implementation before... not so useful, i feel dumb 😵 .

To remedy i've altered a little the mirror sample to mimic what happen in our implementation and managed to reproduce the BSOD TrabacchinLuigi/dokan-dotnet@2744b65148ef435ba304cadd6673a09d17cb86ec

Removing the lock it works fine, but i do think that investigating this behaviour could be useful. Also, dokany should be bullet proof against what the user does in usermode BSOD aren't that good

TrabacchinLuigi commented 5 years ago

Hi guys, back from holidays? Any news on this? Lead to some bug discovery ?

Liryna commented 5 years ago

Hi @TrabacchinLuigi ,

I focus currently https://github.com/dokan-dev/dokany/issues/759 by adding some debug lock logs by default to track such case. Will try to look into this when have time 👍

TrabacchinLuigi commented 5 years ago

Just my impression but i think this could help a lot identify the problem. since it gets into BSOD almost instantly... When i'll have a new pc i could install few virtual machines and debug drivers easier, maybe i could help too then... good luck for now !

TrabacchinLuigi commented 5 years ago

Hi! got the new PC, prepared a VM, installed WinSDK and WDK (i got the newer one, but i think it's ok just for test purposes), made the pipe from local PC to virtual com port and connected to kernel debug succesfully.

Visual studio bothered for some missing spectre/meltdown libs, but i got them installed as-well (not sure if it was better to just disable the fix, but i went for the additive way), now it builds, but i can't find dokan1.sys file... i'm doing something wrong ? visual studio does not complain about errors... so i'm a little confused...

Liryna commented 5 years ago

@TrabacchinLuigi Hi,

Have you selected the correct platform for the build ? "Win10 Debug" for exemple

TrabacchinLuigi commented 5 years ago

I did batch build, then selected Win10 debug|x86 and Win10 Debug|x64 i also selected to build all other projects in debug x86 and x64

TrabacchinLuigi commented 5 years ago

i'm starting to feel dumb... the file is there... just i can't see it from explorer nor console, but if open it from notepad typing the path it exists... i'm sure i have show hidden files and also system files... wtf...

TrabacchinLuigi commented 5 years ago

damn! it was not under the sys project... but in the solution folder... sorry

TrabacchinLuigi commented 5 years ago

C:\Users\LocalAdmin\Desktop>dokanctl.exe /i d Driver path: 'C:\Windows\system32\drivers\dokan1.sys' Installing driver... DokanServiceInstall: Service (Dokan1) installed DokanServiceControl: Failed to start service (Dokan1). error = 577 DokanServiceInstall: Service (Dokan1) start failed Driver install failed

what can i possibly did wrong ?

Liryna commented 5 years ago

Did you add correctly the certificat and enable windows driver option to allow selfsigned driver install ? https://github.com/dokan-dev/dokany/wiki/Build

TrabacchinLuigi commented 5 years ago

So, i've managed to install dokany i've built, i'm running my sample (this version takes longer to crash, maybe because of the incremented max threads), still if i try to open a lot of file the machine hangs in a way which is even worse, CPU skyrockets and become totally unresponsive, i loose connection to the VM and even if i let it run it won't recover after hours... nor i get a minidump. Now i'd like to debug it, so i've tried the named pipe to COM approach and didn't worked quite well so i went for the KDNet approach, i can connect in kernel debug via visual studio, but i'm not hitting breakpoints... Can i have some more hints ? 🆘 💌

TrabacchinLuigi commented 5 years ago

AH! i did it! i had to break execution and run !analyze it loaded symbols and now i can set breakpoints!

TrabacchinLuigi commented 5 years ago

i managed to reproduce it, when it happens it stops on a DbgBreakPoint() i expected to see many threads instead it's just one... if you wanna have a look i can provide screenshots stack trace, variables etc... remote desktop connections...

Liryna commented 5 years ago

Hi @TrabacchinLuigi ,

I try to reproduce this. If I understood correctly. I should just need to change the mirror and change CreateFile:

Sleep(1000);
return STATUS_DEVICE_NOT_READY;

but cannot reproduce a bsod with it. Could you share a C mirror with which create the behavior ?

TrabacchinLuigi commented 5 years ago

I used to reproduce it with a manual reset event during create file, so a thread sleep should do pretty much the same, also the fact that i used a mirror in C# should not make any difference...

Maybe in this version of dokany the problem is gone... i will try a few time

TrabacchinLuigi commented 5 years ago

OK, i still got a blue screen, it's not immediate, just create C:\Test\New image.bmp fire up the hanger version of mirror, go to N:\Test\New image.bmp an try to open it a few times, eventually you'll get the blue screen

Liryna commented 5 years ago

Do you think you can reproduce it on the C mirror ?

TrabacchinLuigi commented 5 years ago

not my fav lang... but i can try...

TrabacchinLuigi commented 5 years ago

Done.

Sleep(1000);
return STATUS_DEVICE_NOT_READY;

on line 454, just before Handle = CreateFile( ... ) Then mount with so it will mirror C: in N: and browse for that folder with a bitmap (it will be slow as hell) open it twice and Boom.

Liryna commented 5 years ago

Thank you @TrabacchinLuigi I will look at it !

Liryna commented 5 years ago

Hi @TrabacchinLuigi ,

I could reproduce using last release 👍 I tried to make it happen on the current master state and seems to be fixed 🏆

Do you think you can try to install last snapshot and run a changed mirror as you did ? https://github.com/dokan-dev/dokany/wiki/Build#user-snapshot https://ci.appveyor.com/project/Maxhy/dokany/builds/24484640/job/519720094o9ia5fv/artifacts

TrabacchinLuigi commented 5 years ago

sure i will, will get u some feedback tomorrow

TrabacchinLuigi commented 5 years ago

Ok, i've tested it with the C implementation and the .net implementation. I can say no more crash happened. I've also wrote a piece of software to open parallel streams of the same file, which i believe is a more reliable way to test it, maybe i can share that too...

Liryna commented 5 years ago

[Open parallel streams is one of the IFSTest already running. Here the issue was more related to "unstable" user FS implementation. Driver is now able to handle this.

That's a good news it also fixed on your side. Thank you again for your report & feedback @TrabacchinLuigi 🎉