BSOD with Dokan 0.7.3 RC on Windows 8.1 Pro x64 about dokany HOT 54 CLOSED

Hello

Can you give me some more informations ?
Do you still have mounted driver when you shutdown ?
Can you make a test with mirror ?

from dokany.

Yes I still have mounted drive when I shutdown.
What is "a test with mirror" ?

from dokany.

In your dokan folder you should have a mirror.exe
https://github.com/dokan-dev/dokany/blob/master/dokan_mirror/mirror.c#L1065

from dokany.

When I type this command
mirror.exe /r d:/ test /l M

Drive M is mounted

from dokany.

What happen if you shutdown when it is mounted ?

from dokany.

When I exit FISSH, mount the drive with mirror.exe and shutdown, there is BSOD

from dokany.

Ok
And if only run mirror.exe without launching at all FISSH ?

from dokany.

Please download the driver from this post BenjaminKim/dokanx#47 and test it. Should work also in your case. If it works fine I will make a pull request and dokany can merge it.

from dokany.

Thank you @marinkobabic but I am not a big fan to installing something that I do not know 😢
Is it possible to commit the changes in your repository ?

from dokany.

Hello

I have installed the driver (right click on the INF file and "Install") and there is still BSOD
I have tested it with both x86 and x64 drivers
I still use Dokan 0.7.3 RC : should I try with other versions?

I forgot to mention it but I have a message when FiSSH start :
"Cannot connect with IPC-Server
Application will now close"

from dokany.

@mapomme1108
Have now made a new version, the download link remains. If you still have a BSOD would be great to get the memory.dmp or some BSOD details. Maybe you can also provide steps to reproduce, even if I must install some software provided by you.

The change I have made now is related to deletion of device object, when keep alive timeout is reached, is not used or if your application was not closed properly and somebody still tries to access the device.

@Liryna
If I provide the changes now, some discussions will start. I would like to fix the BSOD first and you will get the source for sure. You can also try to investigate the BSOD and maybe we will have the same solution at the end.

from dokany.

I have tried the new version but the problem is the same.
Should I install Dokan 0.7.3 RC if I use your driver or is it useless?

BSOD message is : "SYSTEM_SERVICE_EXECPTION = Dokanx.sys"

I have installed WinSSHFS and it is working (I have used FiSSH so far)
I have just had to install WinSSHFS in Windows 7 compatibility mode and it works
WinSSHFS install its own Dokan Library = 0.60 version

from dokany.

You can use the newest dokan library, but my driver. So I have to install https://github.com/tuiSSE/win-sshfs and then run the software. Close it and shutdown the machine to get the BSOD?

from dokany.

Yes you can try but you have to install the Dokan Library 0.7.3 RC first

EDIT : I don't close the software before to shutdown

from dokany.

I'm not able to reproduce your issue with https://github.com/dimov-cz/win-sshfs/releases 1.5.12.5 and dokany version 0.7.1. So please provide me all links of the installers and the steps so that I can reproduce the problem. If I can reproduce it, I will fix the BSOD :-)

from dokany.

So I was able to reproduce the BSOD using FISSH. Please download this driver and perform the test again and let me know if all works as expected. Let's see if you can break this version of the driver.

What here the special case is, is that we have two dokan devices. That is the reason why it's so hard to reproduce this issue.

from dokany.

FYI, with v0.7.3-RC just for a test. i mount folder with the delphi-mirror-sample and shutdown my pc (Win8.1 x64) windows crash (no BSOD). after restart i get a memory dump.

i think, if i would manage WM_QUERYENDSESSION / WM_ENDSESSION, it should unmount correctly, i will check this tomorrow

i don't know, whether there are other ways in the driver, to prevent this behavior

from dokany.

You should never get a BSOD even if your application crashes. Did you try the driver above?

from dokany.

@marinkobabic thank you for your implication, you're helping a lot on Dokan community but if only few people are testing your driver here I believe it is because you just posted binaries without any explanation of your changes. Proceeding like this is not community oriented, and more important it even violates Dokan sys project LGPL license (=> distributing a modified version of the project without the source code). This is definitely not the way it should be done. You should fork the repositories and create a different branch for each of your test.

from dokany.

@marinkobabic i will test only drivers from this repo

from dokany.

I got it to work this way :

1- install Dokan 0.6 (required by winsshfs)
2- install winsshfs 0.0.1.5 from Google code
3- install dokan x86 driver provided by marinkobacic
At this point, there is still BSOD

4- Uninstall Dokan 0.6
5- Install Dokan 0.7.3 RC

no more BSOD on my Win 8.1 Pro x64 PC

from dokany.

? whats the diffent between

1- install Dokan 0.6 (required by winsshfs)

and

3- install dokan x86 driver provided by marinkobacic

isn't Dokan 0.6 a driver?

from dokany.

1- Install Dokan 0.6
= install Dokan library and Dokan x64 driver; the x86 driver won't install because my OS is x64 (Win 8.1 Pro)
2- install winsshfs
3- install Dokan x86 driver provided by marinkobacic
= there are no conflict with other driver because they were not installed in step 1
4- uninstall Dokan 0.6
5- Install Dokan 0.7.3 RC

It works!

from dokany.

@mapomme1108
As you can see in the comment above winsshfs worked from beginning on with latest Rc. Try the same using FISSH and you will fail. No idea why you install a x86 driver on x64 machine.

@Maxhy
I have a fork of dokanx. My commits are just not synced yet. Makes no sense to make a pull request because we have still a not finished discussion about my latest pull request.
If you are not able to reproduce the issues above it will become hard to discuss about the changes because you can't prove them. Don't think the changes would be merged in this case.

from dokany.

@marinkobabic About your pull request, DokanY has sync the part of your pull request that keep the current logic. For us, we think your request is closed.
But as you can see DokanX is practically unmaintained so it gonna be open for a while.

If you want to have feedback and test in your new changes, I highly suggest you to provide a pull request to DokanY.

from dokany.

@Liryna
You are fine. I hate it to make questions and to get no feedback. This was the case in the discussion with Mathy and Benjamin.

By the way my changes related to BSOD are now synced to my fork of dokanx. You can investigate the changes. Feel free to ask if something is not clear. I'm still working on a special BSOD which is hard to reproduce. This one was not reported by community.

from dokany.

i think this one

https://github.com/marinkobabic/dokanx/tree/Windows8DeleteIssue

from dokany.

@marinkobabic Good news ! Thank you alot :) !
@landrix Thank for the quick link !

I will be glad to look at it in the next days 😃

from dokany.

Ok I took a look on your changes @marinkobabic. These look really good, you even removed few code duplication on irp completion and few bugs will be fixed indeed.
I'm just wondering about one fix, the one related to DokanStopCheckThreadInternal / DokanStopEventNotificationThreadInternal functions. I believe you did these changes and use IoQueueWorkItem routine to fix OS shutdown BSOD? Is that because IRQL is higher at shutdown? What's your investigation result here? Thank you.

from dokany.

1. CopleteRequest was sent even if the state was STATUS_PENDING. Using one single method which completes the Irp I can ensure that this does not happen again.
2. The problem which happens rare is that the KeWaitForSingleObject hangs forever. Using the IoAllocateWorkItem I was able to fix the problem.

from dokany.

2- Ok so if I understand well, DokanStopEventNotificationThread will not block but KeWaitForSingleObject in DokanStopEventNotificationThreadInternal will still hangs forever ?

from dokany.

Correct. You can test it using FISSH. Simple way to reproduce is:

1. Run FISSH
2. Drive Z is mounted. Mount a second drive so that we have minimum two dokan devices
3. Restart dokan mounter service
4. Kill FISSH using task manager

from dokany.

Ok I'm confident with your changes now, thank you for the publication and explanations. I ported your fixes to Dokany with commit 837633a
Thanks @marinkobabic.

from dokany.

@mapomme1108 could you try with https://github.com/dokan-dev/dokany/releases/tag/0.7.3-RC2? I wasn't able to reproduce your BSOD with previous version so if this is fixed with this pre-release which include @marinkobabic, please close this issue.

from dokany.

Ok, I will try tomorrow

from dokany.

I have tried FISSH package and Winsshfs with 0.7.3 RC2 but both dont work

There are BSOD on unmount and shutdown with this error message :
"PAGE_FAULT_IN_NONPAGE_AREA"

Maybe I can try on a clean Windows 8.1 install?

from dokany.

Please try it on clean Windows 8.1 and let me know how I can reproduce it.

from dokany.

I'm still having masive problems with BSOD during the development of my app. Whether I close my app or the debug stops it dont seam to matter.

I have an onClose calleback on my c# app where I call dokan.revomeMountPoint('s:') dokan.unmount('s') before exiting but it dose no differens any tip on how do you handle the development cykle? Calling dokanclt.exe /u s return 0 and the app still crache the computer when closing it.

from dokany.

Pleaso do the following:

1. Download the WinDbg
2. File -> Open crash dump
3. Navigate to c:\windows\memory.dmp and open it
4. Type !analyze -v and confirm it with enter
5. Post the content here of the output whenever it changes

Thanks
Marinko

from dokany.

Don't forget to rename the memory dump because the system overwrites it every time you get BSOD. Maybe we need one of them.

from dokany.

According to my modest knowledge: Would it bring something to take a look at the stable system driver of TrueCrypt?

from dokany.

It is right that TrueCrypt have a windows driver but dokan work differently :(

from dokany.

I am experiencing the same issue with the C# mirror sample using 0.7.3 RC2 on Windows 8.1 pro x64.

It does not matter how I exit the app, e.g just close it, or unmount the drive first it causes a BSOD with "PAGE_FAULT_IN_NONPAGE_AREA"

Here's is the output of !analyze -v on my memory dump

5: kd> !analyze -v

•                                                                         *
  

•                    Bugcheck Analysis                                    *
  

•                                                                         *
  

  ---

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: ffffffffffffffd0, memory referenced.
Arg2: 0000000000000001, value 0 = read operation, 1 = write operation.
Arg3: fffff8030f267fb3, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 0000000000000000, (reserved)

Debugging Details:

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

ADDITIONAL_DEBUG_TEXT:
You can run '.symfix; .reload' to try to fix the symbol path and load symbols.

MODULE_NAME: dokan

FAULTING_MODULE: fffff8030f215000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 55a020f0

WRITE_ADDRESS: ffffffffffffffd0

FAULTING_IP:
nt!ObfDereferenceObject+23
fffff803`0f267fb3 f0480fc15ed0 lock xadd qword ptr [rsi-30h],rbx

MM_INTERNAL_CODE: 0

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: AV

CURRENT_IRQL: 0

ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre

LAST_CONTROL_TRANSFER: from fffff8030f39505e to fffff8030f365ca0

STACK_TEXT:
ffffd00021a81368 fffff8030f39505e : 0000000000000050 ffffffffffffffd0 0000000000000001 ffffd00021a815d0 : nt!KeBugCheckEx
ffffd00021a81370 fffff8030f268839 : 0000000000000001 ffffe0014963c080 ffffd00021a815d0 ffffe001528f9080 : nt!CcTestControl+0x2210e
ffffd00021a81410 fffff8030f36ff2f : 0000000000000001 ffffffffffffffff 0000000000000000 fffff8030f2c6226 : nt!ExReleasePushLockEx+0x7d9
ffffd00021a815d0 fffff8030f267fb3 : ffffe0014d860b38 ffffe0014950cb68 ffffe0014950cbd0 ffffe0014d860a00 : nt!setjmpex+0x1f1f
ffffd00021a81760 fffff80174a71af7 : ffffe0014d860da0 ffffe0014d860da0 ffffe00100000000 ffffe00100000000 : nt!ObfDereferenceObject+0x23
ffffd00021a817a0 fffff80174a70afe : ffffe0014d860b38 ffffe0014d860da0 ffffe0014d860a00 ffffe0014d860b38 : dokan+0x5af7
ffffd00021a817e0 fffff80174a6df01 : 00000000c0000002 ffffd00021a81b80 ffffe0014d8608b0 0000000000000000 : dokan+0x4afe
ffffd00021a81830 fffff8030f63a77f : 0000000000000001 ffffe001537fb3e0 ffffe001537fb3e0 0000000000000000 : dokan+0x1f01
ffffd00021a81880 fffff8030f639d22 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!NtDeviceIoControlFile+0xab3
ffffd00021a81a20 fffff8030f3714b3 : ffffd00021a81b10 0000000000000000 ffffd00000000001 00000000005ae4a8 : nt!NtDeviceIoControlFile+0x56
ffffd00021a81a90 0000000077aa2352 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!setjmpex+0x34a3
00000000005aed48 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x77aa2352

STACK_COMMAND: kb

FOLLOWUP_IP:
dokan+5af7
fffff801`74a71af7 4883a39801000000 and qword ptr [rbx+198h],0

SYMBOL_STACK_INDEX: 5

SYMBOL_NAME: dokan+5af7

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: dokan.sys

BUCKET_ID: WRONG_SYMBOLS

FAILURE_BUCKET_ID: WRONG_SYMBOLS

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:wrong_symbols

FAILURE_ID_HASH: {70b057e8-2462-896f-28e7-ac72d4d365f8}

Followup: MachineOwner

from dokany.

Thanks for the analyze @jbrads. Is that a complete/kernel memory dump or a small memory dump (minidump)? If minidump, could you share your dump file for analyze on my side too? Otherwise here is the pdb file for Dokan 0.7.3 RC2 Windows 8.1 x64 driver file: http://wikisend.com/download/541738/dokan.pdb (I tried to use SymbolSource.org to automate symbols publication but it is a bit complicated if you're not using NuGet...). My source files are stored on F:\dev\dokan\dokany.

from dokany.

Your dump would be very interesting if you could provide it. Is it always the same stack trace? Please send us the link to the dump.

from dokany.

Hi, apologies for the delay. It is a complete memory dump at 2.4GB.

Here is the updated output with the symbols loaded, I'll repro the issue and crash my PC now and see if it changes ;)

ADDITIONAL_DEBUG_TEXT:
You can run '.symfix; .reload' to try to fix the symbol path and load symbols.

MODULE_NAME: dokan

FAULTING_MODULE: fffff8030f215000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 55a020f0

WRITE_ADDRESS: ffffffffffffffd0

FAULTING_IP:
nt!ObfDereferenceObject+23
fffff803`0f267fb3 f0480fc15ed0 lock xadd qword ptr [rsi-30h],rbx

MM_INTERNAL_CODE: 0

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: AV

CURRENT_IRQL: 0

ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre

LAST_CONTROL_TRANSFER: from fffff8030f39505e to fffff8030f365ca0

STACK_TEXT:
ffffd00021a81368 fffff8030f39505e : 0000000000000050 ffffffffffffffd0 0000000000000001 ffffd00021a815d0 : nt!KeBugCheckEx
ffffd00021a81370 fffff8030f268839 : 0000000000000001 ffffe0014963c080 ffffd00021a815d0 ffffe001528f9080 : nt!CcTestControl+0x2210e
ffffd00021a81410 fffff8030f36ff2f : 0000000000000001 ffffffffffffffff 0000000000000000 fffff8030f2c6226 : nt!ExReleasePushLockEx+0x7d9
ffffd00021a815d0 fffff8030f267fb3 : ffffe0014d860b38 ffffe0014950cb68 ffffe0014950cbd0 ffffe0014d860a00 : nt!setjmpex+0x1f1f
ffffd00021a81760 fffff80174a71af7 : ffffe0014d860da0 ffffe0014d860da0 ffffe00100000000 ffffe00100000000 : nt!ObfDereferenceObject+0x23
ffffd00021a817a0 fffff80174a70afe : ffffe0014d860b38 ffffe0014d860da0 ffffe0014d860a00 ffffe0014d860b38 : dokan!DokanStopCheckThread+0x73 [f:\dev\dokan\dokany\sys\timeout.c @ 372]
ffffd00021a817e0 fffff80174a6df01 : 00000000c0000002 ffffd00021a81b80 ffffe0014d8608b0 0000000000000000 : dokan!DokanEventRelease+0xf2 [f:\dev\dokan\dokany\sys\notification.c @ 531]
ffffd00021a81830 fffff8030f63a77f : 0000000000000001 ffffe001537fb3e0 ffffe001537fb3e0 0000000000000000 : dokan!DokanDispatchDeviceControl+0x139 [f:\dev\dokan\dokany\sys\device.c @ 485]
ffffd00021a81880 fffff8030f639d22 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!NtDeviceIoControlFile+0xab3
ffffd00021a81a20 fffff8030f3714b3 : ffffd00021a81b10 0000000000000000 ffffd00000000001 00000000005ae4a8 : nt!NtDeviceIoControlFile+0x56
ffffd00021a81a90 0000000077aa2352 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!setjmpex+0x34a3
00000000005aed48 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x77aa2352

STACK_COMMAND: kb

FOLLOWUP_IP:
dokan!DokanStopCheckThread+73 [f:\dev\dokan\dokany\sys\timeout.c @ 372]
fffff801`74a71af7 4883a39801000000 and qword ptr [rbx+198h],0

FAULTING_SOURCE_LINE: f:\dev\dokan\dokany\sys\timeout.c

FAULTING_SOURCE_FILE: f:\dev\dokan\dokany\sys\timeout.c

FAULTING_SOURCE_LINE_NUMBER: 372

SYMBOL_STACK_INDEX: 5

SYMBOL_NAME: dokan!DokanStopCheckThread+73

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: dokan.sys

BUCKET_ID: WRONG_SYMBOLS

FAILURE_BUCKET_ID: WRONG_SYMBOLS

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:wrong_symbols

FAILURE_ID_HASH: {70b057e8-2462-896f-28e7-ac72d4d365f8}

Followup: MachineOwner

from dokany.

Hi, I can confirm in my case it is the same stack trace and location each time

from dokany.

It's a merge issue. Can be fixed very easy. DokanStopCheckThread shoul remove the following lines
KeSetEvent(&Dcb->KillEvent, 0, FALSE);

    if (Dcb->TimeoutThread) {
        KeWaitForSingleObject(Dcb->TimeoutThread, Executive,
            KernelMode, FALSE, NULL);
        ObDereferenceObject(Dcb->TimeoutThread);
        Dcb->TimeoutThread = NULL;
    }

Those lines are part of DokanStopCheckThreadInternal.

from dokany.

@marinkobabic Well find 😄 !
I removed it, will make a RC monday.

from dokany.

Thanks, if you update this issue when the RC is available I will verify.

from dokany.

Thanks for the analyze @jbrads, the issue identification @marinkobabic and the fix @Liryna.
My mistake, I failed the merge and didn't encounter the problem on my tests...

I just published signed drivers @jbrads if you want to test again with latest changes: https://github.com/dokan-dev/dokany/releases/tag/0.7.3-RC3

from dokany.

Thanks, I can confirm I can no longer reproduce this issue with RC3

from dokany.

I can confirm that it also solved the problem for me as well! I tried breaking out of the application over and over again without a hitch. great work! 👍

from dokany.

Works here as well, on win10
On Jul 19, 2015 3:32 PM, "Alexander Morris" [email protected]
wrote:

I can confirm that it also solved the problem for me as well! I tried
breaking out of the application over and over again without a hitch. great
work! [image: 👍]

—
Reply to this email directly or view it on GitHub
#27 (comment).

from dokany.