onexzero commented 2 years ago

Feature request can skip this form. Bug report must complete it. Check List must be 100% match or it will be automatically closed without further discussion. Please remove this line.

Environment

Windows version: windows 10.0.19044.1466
Processor architecture: AMD 5800X
Dokany version: 2.0.1.2000
Library type (Dokany/FUSE): Dokany

Check List

[x] I checked my issue doesn't exist yet
[x] My issue is valid with mirror default sample and not specific to my user-mode driver implementation
[x] I can always reproduce the issue with the provided description below.
[x] I have updated Dokany to the latest version and have reboot my computer after.
[ ] I tested one of the last snapshot from appveyor CI

Description

"insufficient system resources exist to complete the requested service" appears when opening .txt file with notepad. I ran mirror.exe without /n switch as follow. mirror.exe /r C:\Users\raccoon\Desktop\temp /l r:

And that message appeared low probability(about 1/15) when I did open /close repeatedly. So i tested again with dokany 1.5.1 but It worked well even on more slow my own driver with /n switch. No such message poped up. I tested dokany latest version various way. and found that it's more faster than 1.5.x. So I planed to migrate to latest version but this problem occured again. And the ms-office crashing problem a few days ago I issued is solved. Root cause is that dokanOperations.FindStreams returns STATUS_SUCCESS when did not implemented, this makes powerpoint-crash on save or save-as. I think it should be fixed. And now my driver works well on dokany 2.0.1.2000 except this problem.

Logs

Please attach in separate files: mirror output, library logs and kernel logs. In case of BSOD, please attach minidump or dump analyze output.

Liryna commented 2 years ago

Hi @onexzero ,

Where does "insufficient system resources exist to complete the requested service" appears ? Could you share the procmon logs when the issue happens ? I am not able to reproduce the issue

onexzero commented 2 years ago

Hi @Liryna I tested again to collect the requested logs. But strangely enough, I couldn't reproduce it with the Dokan sample. But today I saw this error in my driver and I witnessed it twice while testing with the Dokan sample. Even now, the error does not occur in my 1.5.1000-based driver, and the error appears frequently only in the version upgraded to version 2.0.1.2000. What's the difference? For reference, I am attaching the error log that occurs in my 2.xx based driver. Error Error.zip

onexzero commented 2 years ago

When an error occurs, notepad becomes unresponsive for a long time (about 20 seconds or more) and then appears in notepad.exe.

Liryna commented 2 years ago

It means one of the request timeout. This could be your implementation that is locked somewhere. With procmon you will see which one is it by looking at the status being black for the time notepad is unresponsive and will end with INSUFFICIENT RESOURCES like in the logs you shared.

onexzero commented 2 years ago

But in version 1.5.1000 it doesn't appear at all. Even though the source code is the same...

Liryna commented 2 years ago

Well you and I are not able to reproduce with the sample so I cannot do much here. You could look which of the request always hangs, if it is still the same, if you are seeing it in your filesystem being properly handled.

onexzero commented 2 years ago

Looking at the log, the QueryStandardInformationFile call caused that error and there is no error for that call on the server either. Moreover, there is no code that can cause LOCK.

onexzero commented 2 years ago

If LOCK occurs somewhere and the error is caused, the test was performed more than 200 times in the 1.5.1000-based driver, wouldn't it have to occur at least once? But it's strange that it happens so often in 2.XX. There is currently no way other than to check further. Thanks for the reply.

Liryna commented 2 years ago

Let me know if you are able to get more information on the issue that points to dokan and I will be glad to look into it.

onexzero commented 2 years ago

I replaced notepad.exe with notepad++ and tested it and the error does not occur. It seems to have something to do with the notepad's memory-mapped-io.

onexzero commented 2 years ago

We'll let you know if I find anything odd.

onexzero commented 2 years ago

I think I found the cause of the problem by tracing GetStandardInformationFile. If you look at the attached image cause-pmon.png, the GetStandardInformationFile call started at 12:56:48 at the time of the error, and the Dokan log (cause-dokan.png) shows that GetFileInformation was received at 12:57:07. Also, when the server got the call (serverlog.png) it says 12:57:08 seconds. From this you can see that most of the time was spent before GetFileInformation was called. This seems to be what caused that error. cause-dokan.LOG cause-pmon

Liryna commented 2 years ago

Thanks for the logs. Indeed there is something odd here. The pulling of new events is taking way longer than expected

00004970    12:56:48 AM [6920] Dokan Information: SendAndPullEventInformation() with NTSTATUS 0x0, context 0xd3aa28e0, and result object 0x00000201D5A501A0 with size 48    
00004971    12:57:07 AM [6920] ###Create file handle = 0x00000201D3AD0090, eventID = 3306, event Info = 0x00000201D3AA2720  
00004972    12:57:07 AM [6920] ###GetFileInfo file handle = 0x00000201D3ACFD80, eventID = 3295, event Info = 0x00000201D3ACF920

Could you share the output of fltmc filters ?
Are you able to repro with the driver logs enabled https://github.com/dokan-dev/dokany/blob/master/samples/dokan_mirror/mirror.c#L1646 ?

onexzero commented 2 years ago

Sorry for the late reply because I was sleeping. This doesn't happen very often with driver logs enabled. However, I succeeded in reproducing one case. Driverlog.LOG fltmc

Liryna commented 2 years ago

Without a repro It is going to be very difficult to debug this. Could you please share with details how to get into this state with the samples ?

onexzero commented 2 years ago

There is no special way. It is very difficult to reproduce with sample provided. I attached log reproduced with my own driver.

onexzero commented 2 years ago

When driver log activated, it rarely occurs in my own driver also. But without /e switch it occurs very often.

Liryna commented 2 years ago

@onexzero Can you repro with you filesystem with the single thread mode ?

onexzero commented 2 years ago

Maybe it's possible. I'll try it.

onexzero commented 2 years ago

This is the single-threaded test result. Reproduced using the supplied Mirror sample. SingleThread.zip

onexzero commented 2 years ago

For reference, this is the result of my driver. SingleThread-mine.zip

onexzero commented 2 years ago

You can easily reproduce below command. mirror.exe /r C:\Users\Raccoon\Desktop\test /l r: /e /t /d

Liryna commented 2 years ago

I can see there is something weird in the logs but I am not able to reproduce even with this command line 😢

onexzero commented 2 years ago

That's really a strange phenomenon. I have not installed anything in Windows except ms-office.

Liryna commented 2 years ago

@onexzero

Please uninstall the current Dokan driver you have and reboot.
Install the latest DokanSetupDbg.exe.
Run dokanctl /d 7 to enable lock debug output.
Use DebugView with Kernel log capture enabled.
Try reproduce the issue with mirror.exe /r C:\Users\Raccoon\Desktop\test /l r: /t /d.
Save and share the logs right after it timeout (the 20sec when it no longer hangs) the issue happens

We are trying to find one of those logs https://github.com/dokan-dev/dokany/blob/6bd609be33ae58196e56641095a58a03dd88f682/sys/dokan.c#L636-L702

onexzero commented 2 years ago

The result of reproducing the first time is 1.log. And right away, again. When I open the file, the log is Hang.log. I waited for more than 5 minutes, but there was no message and the notepad kept silent. 1.LOG hang.LOG In this case, pressing Ctrl-C does not end the instance.

onexzero commented 2 years ago

Mount the drive and log until an error occurs. Usually, it's reproduced after about five attempts. But I can't see the message on the source. 2nd.LOG

onexzero commented 2 years ago

I'm attaching a few more for reference. 3rd.LOG 4th.LOG

onexzero commented 2 years ago

Which part of the source code below actually takes a lot of time? PullEvents?? How about taking a log of the time required for each part?

NTSTATUS DokanProcessAndPullEvents(__in PREQUEST_CONTEXT RequestContext) { // 1 - Complete the optional event. // Main pull thread will not have events to complete when: // The file system just started and it is the first pull. // The event completed had no answer to send like Close(). // Other threads from the pool will have an EVENT_INFORMATION // to complete that include the wait timeout for new events. NTSTATUS status = DokanCompleteIrp(RequestContext); if (status != STATUS_BUFFER_TOO_SMALL && status != STATUS_SUCCESS) { DOKAN_LOG_FINE_IRP(RequestContext, "Failed to process IRP"); return status; }

// 2 - Ensure we have enough space to at least store an event before waiting. if (RequestContext->IrpSp->Parameters.DeviceIoControl.OutputBufferLength < sizeof(EVENT_CONTEXT)) { DOKAN_LOG_FINE_IRP(RequestContext, "No output buffer provided"); return status; } // 3 - Flag the device as having workers starting to pull events. RequestContext->Vcb->HasEventWait = TRUE;

PEVENT_INFORMATION eventInfo = (PEVENT_INFORMATION)(RequestContext->Irp->AssociatedIrp.SystemBuffer); ULONG waitTimeoutMs = status == STATUS_BUFFER_TOO_SMALL ? 0 : eventInfo->PullEventTimeoutMs; PLIST_ENTRY listEntry; LARGE_INTEGER timeout; KeQuerySystemTime(&timeout); timeout.QuadPart += waitTimeoutMs * 1000; // Ms to 100 nano

// 4 - Wait for new event indefinitely if we are the main pull thread // or wait for the requested time. ULONG result = KeRemoveQueueEx(&RequestContext->Dcb->NotifyIrpEventQueue, KernelMode, TRUE, waitTimeoutMs ? &timeout : NULL, &listEntry, 1); if (result == STATUS_TIMEOUT) { return STATUS_SUCCESS; } // Were we awake due to the device being unmount ? if (IsUnmountPendingVcb(RequestContext->Vcb)) { DOKAN_LOG_FINE_IRP(RequestContext, "Volume is not mounted"); return STATUS_NO_SUCH_DEVICE; }

// 5 - Fill the provided buffer as much as we can with events. return PullEvents(RequestContext, &RequestContext->Dcb->NotifyEvent); }

Liryna commented 2 years ago

The files are not containg the driver logs:

Forgot to tell the registry need to be changed https://github.com/dokan-dev/dokany/wiki/How-to-Debug-Dokan#windows-configuration

onexzero commented 2 years ago

I attached the requested log.

kernellog1.LOG Kernellog2.LOG Kernellog3.LOG

Liryna commented 2 years ago

00011952    8:34:36 AM  [dokan2][0][DokanDeleteFcb]: Free FCB FFFFA00C30218CC0  
00011953    8:34:36 AM  Stuck trying to lock "\TODO.txt" (ffffa00c30213d00 with ERESOURCE ffffa00c305c2510) in thread ffffa00c2f081080 at DokanCompleteCleanup:160. Current exclusive owner is thread ffffa00c2fbc5080 with outermost lock at DokanFilterCallbackAcquireForCreateSection:152.   
00011954    8:34:37 AM  Stuck trying to lock "\TODO.txt" (ffffa00c30213d00 with ERESOURCE ffffa00c305c2510) in thread ffffa00c2f081080 at DokanCompleteCleanup:160. Current exclusive owner is thread ffffa00c2fbc5080 with outermost lock at DokanFilterCallbackAcquireForCreateSection:152.   
00011955    8:34:38 AM  Stuck trying to lock "\TODO.txt" (ffffa00c30213d00 with ERESOURCE ffffa00c305c2510) in thread ffffa00c2f081080 at DokanCompleteCleanup:160. Current exclusive owner is thread ffffa00c2fbc5080 with outermost lock at DokanFilterCallbackAcquireForCreateSection:152.   
00011956    8:34:39 AM  Stuck trying to lock "\TODO.txt" (ffffa00c30213d00 with ERESOURCE ffffa00c305c2510) in thread ffffa00c2f081080 at DokanCompleteCleanup:160. Current exclusive owner is thread ffffa00c2fbc5080 with outermost lock at DokanFilterCallbackAcquireForCreateSection:152.   
00011957    8:34:40 AM  [dokan2][0][ReleaseTimeoutPendingIrp]: Start    
00011958    8:34:40 AM  [dokan2][0][ReleaseTimeoutPendingIrp]: End  
00011959    8:34:40 AM  Stuck trying to lock "\TODO.txt" (ffffa00c30213d00 with ERESOURCE ffffa00c305c2510) in thread ffffa00c2f081080 at DokanCompleteCleanup:160. Current exclusive owner is thread ffffa00c2fbc5080 with outermost lock at DokanFilterCallbackAcquireForCreateSection:152.   
00011960    8:34:41 AM  Stuck trying to lock "\TODO.txt" (ffffa00c30213d00 with ERESOURCE ffffa00c305c2510) in thread ffffa00c2f081080 at DokanCompleteCleanup:160. Current exclusive owner is thread ffffa00c2fbc5080 with outermost lock at DokanFilterCallbackAcquireForCreateSection:152.   
00011961    8:34:42 AM  Stuck trying to lock "\TODO.txt" (ffffa00c30213d00 with ERESOURCE ffffa00c305c2510) in thread ffffa00c2f081080 at DokanCompleteCleanup:160. Current exclusive owner is thread ffffa00c2fbc5080 with outermost lock at DokanFilterCallbackAcquireForCreateSection:152.   
00011962    8:34:43 AM  Stuck trying to lock "\TODO.txt" (ffffa00c30213d00 with ERESOURCE ffffa00c305c2510) in thread ffffa00c2f081080 at DokanCompleteCleanup:160. Current exclusive owner is thread ffffa00c2fbc5080 with outermost lock at DokanFilterCallbackAcquireForCreateSection:152.   
00011963    8:34:44 AM  Stuck trying to lock "\TODO.txt" (ffffa00c30213d00 with ERESOURCE ffffa00c305c2510) in thread ffffa00c2f081080 at DokanCompleteCleanup:160. Current exclusive owner is thread ffffa00c2fbc5080 with outermost lock at DokanFilterCallbackAcquireForCreateSection:152.   
00011964    8:34:45 AM  [dokan2][0][ReleaseTimeoutPendingIrp]: Start    
00011965    8:34:45 AM  [dokan2][0][ReleaseTimeoutPendingIrp]: End  
00011966    8:34:45 AM  Stuck trying to lock "\TODO.txt" (ffffa00c30213d00 with ERESOURCE ffffa00c305c2510) in thread ffffa00c2f081080 at DokanCompleteCleanup:160. Current exclusive owner is thread ffffa00c2fbc5080 with outermost lock at DokanFilterCallbackAcquireForCreateSection:152.   
00011967    8:34:46 AM  Stuck trying to lock "\TODO.txt" (ffffa00c30213d00 with ERESOURCE ffffa00c305c2510) in thread ffffa00c2f081080 at DokanCompleteCleanup:160. Current exclusive owner is thread ffffa00c2fbc5080 with outermost lock at DokanFilterCallbackAcquireForCreateSection:152.   
00011968    8:34:47 AM  Stuck trying to lock "\TODO.txt" (ffffa00c30213d00 with ERESOURCE ffffa00c305c2510) in thread ffffa00c2f081080 at DokanCompleteCleanup:160. Current exclusive owner is thread ffffa00c2fbc5080 with outermost lock at DokanFilterCallbackAcquireForCreateSection:152.   
00011969    8:34:48 AM  Stuck trying to lock "\TODO.txt" (ffffa00c30213d00 with ERESOURCE ffffa00c305c2510) in thread ffffa00c2f081080 at DokanCompleteCleanup:160. Current exclusive owner is thread ffffa00c2fbc5080 with outermost lock at DokanFilterCallbackAcquireForCreateSection:152.   
00011970    8:34:49 AM  Stuck trying to lock "\TODO.txt" (ffffa00c30213d00 with ERESOURCE ffffa00c305c2510) in thread ffffa00c2f081080 at DokanCompleteCleanup:160. Current exclusive owner is thread ffffa00c2fbc5080 with outermost lock at DokanFilterCallbackAcquireForCreateSection:152.

Liryna commented 2 years ago

This is actually a dup of https://github.com/dokan-dev/dokany/issues/831

From what I see in the logs:

There is a create / QueryInformation that is processed under DokanFilterCallbackAcquireForCreateSection lock.
The QueryInformation that owns the lock is pending to be executed (pulled by userland).
A cleanup on the same object that tries to be completed in Kernel which cannot happen until the query is processed by userland.

This should not happen if userland has multiple threads that can pull and send the response on separate thread.

That's why /t that execute one request at a time make it easier to reproduce. Now I am wondering if your VM has enough threads and is actually running request in parallel ?

onexzero commented 2 years ago

Then why doesn't the problem occur at 1.5.x? And why does the problem only occur on the note pad? I test using vmware. Isn't it weird that the problem only occurs in the 2.x version in the same environment?

onexzero commented 2 years ago

You said you can't reproduce errors before. What kind of vm software do you use?

onexzero commented 2 years ago

Another. If I give the /e option to my 2.x based driver, the frequency of errors will be significantly reduced, but I don't understand this either.

Liryna commented 2 years ago

I am also using Vmware but we probably have a different hardware config. Like you could have allocated only one core to the VM. You can try to add more cores.

Version 2 has a different pulling event and use the windows pool thread instead of 5 dedicated thread. It is possible that your thread pool is very small due to the VM allocated resources.

This is a timing issue and /e will add some events between the request which can break this timing.

The FCB locking in kernel should be improved to avoid such situations. I created a new issue #1060 for this. It requires changes in the library if you are interested.

onexzero commented 2 years ago

I don't have experience in developing kernel drivers, so I can't understand what you're saying exactly. However, I think my vm is also allocated two cores and enough memory. And the test results so far make me hesitate to move to the 2.x version. Sooner or later, I'm going to test it on the real machine or on different vm. And can the library improvement you mentioned in #1060 solve this problem? What is the shared object specifically?

Liryna commented 2 years ago

Yes #1060 is one step to improve this situation be removing all the DokanFCBLockRW(fcb); that are only used to pass the FileName to userland which is an information that was already provided at CreateFile time. https://github.com/dokan-dev/dokany/blob/master/sys/cleanup.c#L97

Like here where the kernel copy the FileName https://github.com/dokan-dev/dokany/blob/master/sys/cleanup.c#L97-L116 so userland can just pass it to the user filesystem here https://github.com/dokan-dev/dokany/blob/master/dokan/cleanup.c#L41

onexzero commented 2 years ago

I need to study the source code tomorrow. Thank you in many ways.

onexzero commented 2 years ago

I just tested it on a real machine with my own driver, not a VM. Strangely, the frequency and form of errors are the same. ReadMachine.zip .

onexzero commented 2 years ago

I saw that when Notepad.exe opened the file, the following consecutive GetFileInformation calls were made. Why is this necessary? Does it mean that successive calls should be processed in parallel?

00000402 오전 8:50:42 [14156] MIRROR>GetFileInfo : \test\1111.txt, HANDLE = 9 00000403 오전 8:50:42 [14156] ....MIRROR>>GetFileInformation success, file size = 13116
00000404 오전 8:50:42 [14156] ....MIRROR>FILE ATTRIBUTE = 0
00000405 오전 8:50:42 [14156] result = 0
00000406 오전 8:50:42 [14156] FileBasicInformation
00000407 오전 8:50:42 [14156] DispatchQueryInformation result = 0
00000408 오전 8:50:42 [14156] Dokan Information: SendAndPullEventInformation() with NTSTATUS 0x0, context 0xf3a28bb0, and result object 0x000001B7F3A12840 with size 80
00000409 오전 8:50:42 [14156] ###GetFileInfo file handle = 0x000001B7F3A28BB0, eventID = 3998, event Info = 0x000001B7F3991AD0
00000410 오전 8:50:42 [14156] MIRROR>GetFileInfo : \test\1111.txt, HANDLE = 9 00000411 오전 8:50:42 [14156] ....MIRROR>>GetFileInformation success, file size = 13116
00000412 오전 8:50:42 [14156] ....MIRROR>FILE ATTRIBUTE = 0
00000413 오전 8:50:42 [14156] result = 0
00000414 오전 8:50:42 [14156] FileInternalInformation
00000415 오전 8:50:42 [14156] DispatchQueryInformation result = 0
00000416 오전 8:50:43 [14156] Dokan Information: SendAndPullEventInformation() with NTSTATUS 0x0, context 0xf3a28bb0, and result object 0x000001B7F3A12840 with size 48
00000417 오전 8:50:43 [14156] ###GetFileInfo file handle = 0x000001B7F3A28BB0, eventID = 3998, event Info = 0x000001B7F3991AD0
00000418 오전 8:50:43 [14156] MIRROR>GetFileInfo : \test\1111.txt, HANDLE = 9 00000419 오전 8:50:43 [14156] ....MIRROR>>GetFileInformation success, file size = 13116
00000420 오전 8:50:43 [14156] ....MIRROR>FILE ATTRIBUTE = 0
00000421 오전 8:50:43 [14156] result = 0
00000422 오전 8:50:43 [14156] FileStandardInformation
00000423 오전 8:50:43 [14156] DispatchQueryInformation result = 0
00000424 오전 8:50:43 [14156] Dokan Information: SendAndPullEventInformation() with NTSTATUS 0x0, context 0xf3a28bb0, and result object 0x000001B7F3A12840 with size 64
00000425 오전 8:50:43 [14156] ###GetFileInfo file handle = 0x000001B7F3A28BB0, eventID = 3998, event Info = 0x000001B7F3991AD0
00000426 오전 8:50:43 [14156] MIRROR>GetFileInfo : \test\1111.txt, HANDLE = 9 00000427 오전 8:50:43 [14156] ....MIRROR>>GetFileInformation success, file size = 13116
00000428 오전 8:50:43 [14156] ....MIRROR>FILE ATTRIBUTE = 0
00000429 오전 8:50:43 [14156] result = 0
00000430 오전 8:50:43 [14156] FileInternalInformation
00000431 오전 8:50:43 [14156] DispatchQueryInformation result = 0
00000432 오전 8:50:43 [14156] Dokan Information: SendAndPullEventInformation() with NTSTATUS 0x0, context 0xf3a28bb0, and result object 0x000001B7F3A12840 with size 48
00000433 오전 8:50:43 [14156] ###GetFileInfo file handle = 0x000001B7F3A28BB0, eventID = 3998, event Info = 0x000001B7F3991AD0
00000434 오전 8:50:43 [14156] MIRROR>GetFileInfo : \test\1111.txt, HANDLE = 9 00000435 오전 8:50:43 [14156] ....MIRROR>>GetFileInformation success, file size = 13116
00000436 오전 8:50:43 [14156] ....MIRROR>FILE ATTRIBUTE = 0
00000437 오전 8:50:43 [14156] result = 0
00000438 오전 8:50:44 [14156] unknown type:55
00000439 오전 8:50:44 [14156] DispatchQueryInformation result = c000000d
00000440 오전 8:50:44 [14156] Dokan Information: SendAndPullEventInformation() with NTSTATUS 0xc000000d, context 0xf3a28bb0, and result object 0x000001B7F3A12840 with size 48
00000441 오전 8:50:44 [14156] ###GetFileInfo file handle = 0x000001B7F3A28BB0, eventID = 3998, event Info = 0x000001B7F3991AD0
00000442 오전 8:50:44 [14156] MIRROR>GetFileInfo : \test\1111.txt, HANDLE = 9 00000443 오전 8:50:44 [14156] ....MIRROR>>GetFileInformation success, file size = 13116
00000444 오전 8:50:44 [14156] ....MIRROR>FILE ATTRIBUTE = 0
00000445 오전 8:50:44 [14156] result = 0
00000446 오전 8:50:44 [14156] FileStandardInformation
00000447 오전 8:50:44 [14156] DispatchQueryInformation result = 0
00000448 오전 8:50:44 [14156] Dokan Information: SendAndPullEventInformation() with NTSTATUS 0x0, context 0xf3a28bb0, and result object 0x000001B7F3A12840 with size 64
00000449 오전 8:50:44 [14156] ###GetFileInfo file handle = 0x000001B7F3A28BB0, eventID = 3998, event Info = 0x000001B7F3991AD0
00000450 오전 8:50:44 [14156] MIRROR>GetFileInfo : \test\1111.txt, HANDLE = 9 00000451 오전 8:50:44 [14156] ....MIRROR>>GetFileInformation success, file size = 13116
00000452 오전 8:50:44 [14156] ....MIRROR>FILE ATTRIBUTE = 0
00000453 오전 8:50:44 [14156] result = 0
00000454 오전 8:50:44 [14156] FileBasicInformation
00000455 오전 8:50:44 [14156] DispatchQueryInformation result = 0
00000456 오전 8:50:44 [14156] Dokan Information: SendAndPullEventInformation() with NTSTATUS 0x0, context 0xf3a28bb0, and result object 0x000001B7F3A12840 with size 80
00000457 오전 8:50:44 [14156] ###GetFileInfo file handle = 0x000001B7F3A28BB0, eventID = 3998, event Info = 0x000001B7F3991AD0
00000458 오전 8:50:44 [14156] MIRROR>GetFileInfo : \test\1111.txt, HANDLE = 9 00000459 오전 8:50:44 [14156] ....MIRROR>>GetFileInformation success, file size = 13116
00000460 오전 8:50:44 [14156] ....MIRROR>FILE ATTRIBUTE = 0
00000461 오전 8:50:44 [14156] result = 0
00000462 오전 8:50:45 [14156] FileStandardInformation
00000463 오전 8:50:45 [14156] DispatchQueryInformation result = 0
00000464 오전 8:50:45 [14156] Dokan Information: SendAndPullEventInformation() with NTSTATUS 0x0, context 0xf3a28bb0, and result object 0x000001B7F3A12840 with size 64
00000465 오전 8:50:45 [14156] ###Cleanup file handle = 0x000001B7F3A28BB0, eventID = 3998, event Info = 0x000001B7F3991AD0
00000466 오전 8:50:45 [14156] MIRROR>Cleanup: \test\1111.txt

Liryna commented 2 years ago

@onexzero The shared logs are not containing the driver logs.

Regarding all the different getinformation types...could you compare with the sample when there is no issue ? Is that the same ? What could explain the difference ? Same data are provided to the kernel ?

onexzero commented 2 years ago

I did not collect Kernel logs because the error types were the same with vm. If you need it, I'll collect them.

Above my question is that when notepad opens a file(see attached image), the GetFileInformation type call is approximately 6 times on procmon log. But if you look at Dokan log, GetFileInformation is called more than 30 times on 1111.txt, why is that? Is it supposed to be like that? It is. dokanlog procmon

Liryna commented 2 years ago

That could be a normal behavior. Only way to know is to compare the procmon logs with the same steps on NTFS.

onexzero commented 2 years ago

OK, Thanks you!

onexzero commented 2 years ago

I tested it without /t switch using the .bat file. (mirror.exe /r C:\Users\Raccoon\Desktop\test /l r: /d) This phenomenon was easily reproduced. I attached the log and bat file. Open and edit .bat file to match the path and run it. Test.zip

onexzero commented 2 years ago

for reference.. multi.LOG

https://user-images.githubusercontent.com/31300523/152283757-8f341cfa-e09c-4720-ab12-4fa0160cd70e.mp4

multi2.LOG

https://user-images.githubusercontent.com/31300523/152283807-8dbfe619-36b2-4065-b7d3-10bf67a13ca4.mp4

onexzero commented 2 years ago

Great job! that fixed the problem. I tested it more than 1000 times without /t switch. it worked as expected!!

onexzero commented 2 years ago

After testing a bit more, when run with /t switch, the drive is mounted, but if you click it, you will get HANG. After a while, the same message popped up from windows explorer. My own driver works well if without /t switch too. SingleThread.LOG

dokan-dev / dokany

insufficient system resources exist to complete the requested service #1058

Environment

Check List

Description

Logs