insufficient system resources exist to complete the requested service #1058

onexzero · 2022-01-29T08:50:24Z

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

I checked my issue doesn't exist yet
My issue is valid with mirror default sample and not specific to my user-mode driver implementation
I can always reproduce the issue with the provided description below.
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.

The text was updated successfully, but these errors were encountered:

Liryna · 2022-01-29T13:00:29Z

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 · 2022-01-29T15:05:46Z

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.zip

onexzero · 2022-01-29T15:11:41Z

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

Liryna · 2022-01-29T15:14:12Z

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 · 2022-01-29T15:16:03Z

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

Liryna · 2022-01-29T15:20:50Z

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 · 2022-01-29T15:25:17Z

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 · 2022-01-29T15:31:24Z

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 · 2022-01-29T15:41:13Z

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 · 2022-01-29T15:45:12Z

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 · 2022-01-29T15:47:42Z

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

onexzero · 2022-01-29T16:27:30Z

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

Liryna · 2022-01-29T17:09:42Z

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 · 2022-01-29T23:54:56Z

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

Liryna · 2022-01-30T15:10:29Z

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 · 2022-01-30T17:05:43Z

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

onexzero · 2022-01-30T17:18:20Z

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

Liryna · 2022-01-30T17:43:44Z

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

onexzero · 2022-01-31T01:20:55Z

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

onexzero · 2022-01-31T01:45:57Z

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

onexzero · 2022-01-31T02:00:31Z

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

onexzero · 2022-01-31T02:04:52Z

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

Liryna · 2022-01-31T02:26:17Z

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

onexzero · 2022-01-31T02:37:19Z

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

Liryna · 2022-01-31T12:33:27Z

@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

dokany/sys/dokan.c

Lines 636 to 702 in 6bd609b

    
           VOID DokanLockWarn(__in const ERESOURCE *Resource, 
        
                              __in const DokanResourceDebugInfo *DebugInfo, 
        
                              __in PDOKAN_LOGGER Logger, 
        
                              __in const char *Site, 
        
                              __in const UNICODE_STRING *ObjectName, 
        
                              __in const void *ObjectPointer) { 
        
             if (ObjectName == NULL || ObjectName->Length == 0) { 
        
               ObjectName = &noName; 
        
             } 
        
             if (DebugInfo->ExclusiveOwnerThread != NULL) { 
        
               DokanLogInfo( 
        
                   Logger, 
        
                   L"Stuck trying to lock \"%wZ\" (%I64x with ERESOURCE %I64x)" 
        
                       L" in thread %I64x at %S." 
        
                       L" Current exclusive owner is thread %I64x" 
        
                       L" with outermost lock at %S.", 
        
                   ObjectName, 
        
                   ObjectPointer, 
        
                   Resource, 
        
                   KeGetCurrentThread(), 
        
                   Site, 
        
                   DebugInfo->ExclusiveOwnerThread, 
        
                   DebugInfo->ExclusiveLockSite); 
        
               // This is like DDbgPrint but gets written "unconditionally" as long as you 
        
               // have the Debug Print Filter set up in the registry. Normal DDbgPrint 
        
               // calls are utterly stripped from release builds. We know that 
        
               // DokanLockWarn doesn't get invoked unless DriveFS is in lock debug mode, 
        
               // so this is OK. 
        
               DbgPrintEx( 
        
                   DPFLTR_IHVDRIVER_ID, 
        
                   DPFLTR_TRACE_LEVEL, 
        
                   "Stuck trying to lock \"%wZ\" (%I64x with ERESOURCE %I64x)" 
        
                       " in thread %I64x at %s." 
        
                       " Current exclusive owner is thread %I64x" 
        
                       " with outermost lock at %s.\n", 
        
                   ObjectName, 
        
                   ObjectPointer, 
        
                   Resource, 
        
                   KeGetCurrentThread(), 
        
                   Site, 
        
                   DebugInfo->ExclusiveOwnerThread, 
        
                   DebugInfo->ExclusiveLockSite); 
        
             } else { 
        
               DokanLogInfo( 
        
                   Logger, 
        
                   L"Stuck trying to lock \"%wZ\" (%I64x with ERESOURCE %I64x)" 
        
                       L" in thread %I64x at %S." 
        
                       L" This resource has an unknown shared lock.", 
        
                   ObjectName, 
        
                   ObjectPointer, 
        
                   Resource, 
        
                   KeGetCurrentThread(), 
        
                   Site); 
        
               DbgPrintEx( 
        
                   DPFLTR_IHVDRIVER_ID, 
        
                   DPFLTR_TRACE_LEVEL, 
        
                   "Stuck trying to lock \"%wZ\" (%I64x with ERESOURCE %I64x)" 
        
                       " in thread %I64x at %s." 
        
                       " This resource has an unknown shared lock.\n", 
        
                   ObjectName, 
        
                   ObjectPointer, 
        
                   Resource, 
        
                   KeGetCurrentThread(), 
        
                   Site); 
        
             } 
        
           }

onexzero · 2022-01-31T14:20:38Z

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 · 2022-01-31T14:42:34Z

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 · 2022-02-09T07:52:59Z

Profiling report collected on real machine.
Report20220209-1643.zip

onexzero · 2022-02-09T08:43:13Z

Profiling result on VM
vmtest.zip
cpu.zip

Liryna · 2022-02-14T00:47:02Z

@onexzero I pushed new changes that overall improves the read and write scenario.

onexzero · 2022-02-14T01:04:56Z

Ok. I'll test it.

Liryna · 2022-02-14T01:11:48Z

@onexzero There is no version. All changes are in the library. You can just pull the new changes and build if you want to test them.

onexzero · 2022-02-14T01:13:01Z

Ok. I'll test it.

Liryna · 2022-02-14T04:18:19Z

See https://github.com/dokan-dev/dokany/releases/tag/v2.0.3.1000

onexzero · 2022-02-14T05:17:52Z

Excellent work! Performance has improved remarkably. I've tested several things and haven't found any issues yet.

Liryna · 2022-02-15T01:00:19Z

Thanks for the feedback @onexzero 👍 Glad we got it solved!

onexzero · 2022-05-19T08:10:03Z

@Liryna hi~
I tested the latest version (2.0.4.1) module today, but it seems that this issue has not been completely resolved.
I've been repeatedly opening mp4 video files on my drive, and found that in some cases the video takes significantly longer than usual to play. Additionally, i tested other types of files and found that there were occasional, time-consuming cases.
A file that normally opened in 2-3 seconds took more than 20-30 seconds. When I checked the process monitor, "Insuffient resource..." is also occurring.
I have attached the relevant log and PNG file. If you look at the PNG file, you will find some strange parts. This issue doesn't seem to be caused by the latest version of the module. I've tried with the previous version, but the same thing happens.

Strange.zip

Liryna · 2022-05-19T12:35:39Z

The driver logs looks fine. The Create request around before the gap between 26 and 38 are completed at 26 and we see the library logs. The Create failing with INSUFFICIENT_RESOURCES is also happening quickly.

Can this be repro with samples ? on any computers ?

onexzero · 2022-05-20T02:06:13Z

It's very difficult to reproduce with a sample, but I'll give it a try.
However, this problem appears to be the same as the one discussed above.
#1058 (comment)

Liryna · 2022-05-20T02:19:08Z

Even if the result looks the same, I am not able to see the same trace/events in the driver logs.

onexzero · 2022-05-20T02:20:03Z

All operations before and after INSUFFICIENT_RESOURCES were taking a long time to complete. CloseFile also took 18 seconds. What was the cause? I checked the server side logs, but couldn't find the part that took that long. It looks like there is some kind of problem with LOCK.

Liryna · 2022-05-20T02:33:02Z

From the logs you provided, the close happens in the library at the right time. When you say lock issue it is a guess or you located it?

onexzero · 2022-05-20T02:57:07Z

C:\Users\raccoon\Desktop\mirror>mirror /r C:\Users\raccoon\Desktop\Temp /l r /e /d /n \localhost\dokan

Contrary to what I thought, it was reproduced well with the Dokan sample.
If you look around 11:37:42, CloseFile takes a strangely long time and you can see that the error occurs as in my driver.

dokansample.LOG
dokansample.zip

onexzero · 2022-05-20T02:59:27Z

Regarding LOCK, it's just speculation. It's just a feeling, so don't worry too much.

onexzero · 2022-05-20T05:47:12Z

Same result on local drive emulation mode.
mirror /r C:\Users\raccoon\Desktop\Temp /l r /e /d

localdrive.zip

onexzero · 2022-05-20T09:06:14Z

I think I've found a pattern for this problem.
It was strange that SendAndPullEventInformation() appeared in two lines in the log whenever INSUFFICIENT_RESOURCE occurred during the test. Please see the attached PNG.
It's a guess, but there seems to be some racing problem.
pattern.zip

onexzero · 2022-05-21T05:44:16Z

In programs that retry when an error occurs, such as Windows movie player, responsiveness can be improved by adjusting the timeout value of DokanOption and the value of dokan_check_interval, but it is still a problem in programs that immediately popup errors such as Notepad.exe. It seems that we need to find the root cause of the INSUFFICIENT_RESOURCE problem.
I don't know why I get INSUFFICIENT_RESOURCE so often on 4-core machines.

onexzero · 2022-05-21T06:56:27Z

Finally found the root cause. The pull thread count is set too low. When I edit the source in 4-Core VM and take a log, it comes out as 2. I don't think this was originally intended. I forced it to 8 and the problem went away.

Liryna · 2022-05-21T12:23:12Z

Normally we should detect your 4 Core and set 4 threads https://github.com/dokan-dev/dokany/blob/master/dokan/dokan.c#L778-L783
2 threads would mean whether you have 1 Core or 2 Core detected and we enforce DOKAN_MAIN_PULL_THREAD_COUNT_MIN

onexzero · 2022-05-21T15:19:18Z

Matching the number of threads to the number of cores may seem ideal, but according to actual test results, it is not enough. That is, the error occurs intermittently even when set to 4-thread. I think several factors such as core speed are related to this problem. How about making it configurable as in the previous version?

Liryna · 2022-05-22T12:07:48Z

@onexzero I think the issue might be different. Could you reset all your local changes and give a try to a31981d ?
The create request being canceled should not wait for that interval that you also manually changed.
FYI I wasn't able to find the issue in #1058 (comment) logs, please continue to test on network drive for now and lets see after the local type

onexzero · 2022-05-23T01:21:27Z

This is the result of applying the patch and testing it. I don't know much of a difference.
As you may know, the reason I changed DOKAN_CHECK_TIME when the root cause was unknown was to reduce recovery time when an error occurred.

onexzero · 2022-05-23T01:33:33Z

"The create request being canceled should not wait for that interval that you also manually changed. "

What does this sentence mean?
I know that if the pending IRP is not processed within the timeout time, it is canceled and returned as an INSUFFICIENT error, did I misunderstand?
I analyzed the log for the case of emulation with a local drive, but this case is different.
In this case, it seems that the INSUFFICIENT_BUFFER error caused the delay. From the test results, even in this case, as you said, it looks like the process is waiting instead of returning immediately. Are you talking about this case?

I tested the patch in local drive mode using the Dokan sample. There was no lag when running the player. However, the process monitor has the following logs:

Liryna · 2022-05-23T11:38:19Z

Could you provide the exact app, windows version and steps so I can reproduce the issue on my side ?

It would be interesting to know whether it is canceled by

dokany/sys/event.c

Line 32 in 6bd609b

VOID DokanCreateIrpCancelRoutine(_Inout_ PDEVICE_OBJECT DeviceObject,

or

dokany/sys/create.c

Line 329 in e9f4bef

VOID DokanRetryCreateAfterOplockBreak(__in PVOID Context, __in PIRP Irp) {

because is does not looks like it is a timeout if you can make the create return faster by changing the DOKAN_CHECK_INTERVAL
Unfortunately there is no logs in those functions 😢 (Also if you add logs there, they might not be forward to userland, it would need to have the "real" debugger attach to see them)

Do you see this log in your system EventLog

dokany/sys/timeout.c

Line 255 in 2352816

DokanLogInfo(&logger, L"Wake from sleep detected.");

?

onexzero · 2022-05-24T01:38:00Z

Windows 10 pro 32bit 19044 (run on 4-Core VM)

mirror /r C:\Users\raccoon\Desktop\Temp /l r
Double-click the mp4 file in r: -> Movies & TV app launch
That's all.

"Wake from sleep detected." was not found in the event log.

The attempt to improve response time by reducing DOKAN_CHECK_TIME and Timeout was based on the following log. Results are already at #1058 (comment)

00048074	533.45446777	[1656] DriverLog: [11:45:13.848][DokanDispatchRequest][FFFF96831B6BC8A0][VCB][IRP_MJ_CREATE][]: Begin ProcessId=6236	
00048075	533.45544434	[1656] DriverLog: [11:45:13.848][DokanDispatchCreate][FFFF96831B6BC8A0]: FileObject=FFFF968319F24590 RelatedFileObject=0000000000000000 FileName="\" Flags=0 DesiredAccess=80 Options=1200000 FileAttributes=0 ShareAccess=7	
00048076	533.45642090	[1656] DriverLog: [11:45:13.848][DokanCompareFcb]: First: FFFF96831BEC9D50 \ Second: FFFF96831A80A010 \drive_fs_notification - Result: -21	
00048077	533.45782471	[1656] DriverLog: [11:45:13.848][DokanGetFCB][FFFF96831B6BC8A0]: New FCB FFFF96831BEC9D50 allocated for \	
00048078	533.45886230	[1656] DriverLog: [11:45:13.848][DokanDispatchCreate][FFFF96831B6BC8A0]: Use FCB=FFFF96831BEC9D50	
00048079	533.45977783	[1656] DriverLog: [11:45:13.848][DokanAllocateCCB][FFFF96831B6BC8A0]: Allocated CCB=FFFF96831DF03E00	
00048080	533.46081543	[1656] DriverLog: [11:45:13.848][DokanRegisterPendingIrp][FFFF96831B6BC8A0]: Register the IRP pending	
00048081	533.46173096	[1656] ###Create file handle = 0x00000238846518B0, eventID = 0452, event Info = 0x00000238845EFF40	
00048082	533.46276855	[1656] DriverLog: [11:45:13.848][DokanRegisterPendingIrp][FFFF96831B6BC8A0]: Pending Registration: STATUS_PENDING	
00048083	533.46386719	[1656] CreateFile : C:\Users\raccoon\Desktop\Temp\	

> 00048084	533.46484375	[1656] DriverLog: [11:45:13.848][DokanDispatchRequest][FFFF96831B6BC8A0]: End - Irp is marked pending	

00048085	533.46588135	[1656] DokanError: Ioctl 0x92030 failed with code 87 on Device \\.\DokanRedirector2{d6cc17c5-1734-4085-bce7-964f1e9f5de9}	

> 00048086	533.46691895	[1656] DriverLog: [11:45:18.754][ReleaseTimeoutPendingIrp]: Start	
> 00048087	533.84246826	[1656] DriverLog: [11:45:18.754][ReleaseTimeoutPendingIrp]: End

	
00048088	533.84429932	[1656]   DokanOpenRequestorToken failed	

> 00048089	533.84539795	[1656] DriverLog: [11:45:23.739][ReleaseTimeoutPendingIrp]: Start	
> 00048090	533.84637451	[1656]  ShareMode = 0x7	
> 00048091	533.84747314	[1656] DriverLog: [11:45:23.739][ReleaseTimeoutPendingIrp]: End

	
00048092	533.84844971	[1656]  FILE_SHARE_READ	
00048093	533.84942627	[1656] DriverLog: [11:45:23.848][DokanDispatchRequest][FFFF96831A2F02C0][DGL][IRP_MJ_CREATE][]: Begin ProcessId=4724	
00048094	533.85052490	[1656]  FILE_SHARE_WRITE	
00048095	533.85162354	[1656] DriverLog: [11:45:23.848][DokanDispatchCreate][FFFF96831A2F02C0]: FileObject=FFFF96831D651DD0 RelatedFileObject=0000000000000000 FileName="(null)" Flags=0 DesiredAccess=100080 Options=1000060 FileAttributes=0 ShareAccess=3	
00048096	533.85260010	[1656]  FILE_SHARE_DELETE	
00048097	533.85400391	[1656] DriverLog: [11:45:23.848][DokanDispatchRequest][FFFF96831A2F02C0]: End - STATUS_SUCCESS Information=0	
00048098	533.85498047	[1656]  DesiredAccess = 0x80	
00048099	533.85595703	[1656] DriverLog: [11:45:23.848][DokanDispatchRequest][FFFF96831A2F02C0][DGL][IRP_MJ_FILE_SYSTEM_CONTROL][IRP_MN_USER_FS_REQUEST]: Begin ProcessId=4724	
00048100	533.85693359	[1656]  FILE_READ_ATTRIBUTES	
00048101	533.85797119	[1656] DriverLog: [11:45:23.848][DokanUserFsRequest][FFFF96831A2F02C0][FSCTL_EVENT_MOUNTPOINT_LIST]: FileObject=FFFF96831D651DD0	
00048102	533.85913086	[1656]  FlagsAndAttributes = 0x200000	
00048103	533.86016846	[1656] DriverLog: [11:45:23.848][DokanDispatchRequest][FFFF96831A2F02C0]: End - STATUS_SUCCESS Information=314	
00048104	533.86114502	[1656]  FILE_FLAG_OPEN_REPARSE_POINT	
00048105	533.86218262	[1656] DriverLog: [11:45:23.848][DokanDispatchRequest][FFFF96831A2F02C0][DGL][IRP_MJ_CLEANUP][]: Begin ProcessId=4724	
00048106	533.86315918	[1656]  OPEN_EXISTING	
00048107	533.86413574	[1656] DriverLog: [11:45:23.848][DokanDispatchCleanup][FFFF96831A2F02C0]: FileObject=FFFF96831D651DD0	
00048108	533.86511230	[1656] 	
00048109	533.86614990	[1656] DriverLog: [11:45:23.848][DokanDispatchRequest][FFFF96831A2F02C0]: End - STATUS_SUCCESS Information=0	
00048110	533.86712646	[1656] Dokan Information: DokanEndDispatchCreate() status = 0, file handle = 0x00000238846518B0, eventID = 0452, result = 0x1	
00048111	533.86810303	[1656] DriverLog: [11:45:23.848][DokanDispatchRequest][FFFF96831A2F02C0][DGL][IRP_MJ_CLOSE][]: Begin ProcessId=4724	
00048112	533.86914063	[1656] Dokan Information: SendAndPullEventInformation() with NTSTATUS 0x0, context 0x846518b0, and result object 0x000002388464D490 with size 48	
00048113	533.87011719	[1656] DriverLog: [11:45:23.848][DokanDispatchClose][FFFF96831A2F02C0]: FileObject=FFFF96831D651DD0	
00048114	533.87109375	[1656] DriverLog: [11:45:23.848][DokanDispatchRequest][FFFF96831A2F02C0]: End - STATUS_SUCCESS Information=0	

> 00048115	533.87213135	[1656] DriverLog: [11:45:28.739][ReleaseTimeoutPendingIrp]: Start	
> 00048116	533.87310791	[1656] DriverLog: [11:45:28.739][ReleaseTimeoutPendingIrp]: End	

> 00048117	533.87438965	[1656] DriverLog: [11:45:33.741][ReleaseTimeoutPendingIrp]: Start	
> 00048118	533.87542725	[1656] DriverLog: [11:45:33.741][DokanCompleteCreate][FFFF96831B6BC8A0]: FileObject=FFFF968319F24590 CreateInformation=FILE_SUPERSEDED	
> 00048119	533.87634277	[1656] DriverLog: [11:45:33.741][DokanFreeCCB][FFFF96831B6BC8A0]: Free CCB=FFFF96831DF03E00	
> 00048120	533.87738037	[1656] DriverLog: [11:45:33.741][DokanCancelCreateIrp][FFFF96831B6BC8A0]: End - STATUS_INSUFFICIENT_RESOURCES Information=0	
> 00048121	533.87835693	[1656] DriverLog: [11:45:33.741][ReleaseTimeoutPendingIrp]: End

Liryna closed this as completed Jan 29, 2022

onexzero mentioned this issue Jan 29, 2022

I found cause of insufficient system resources.. problem. #1059

Closed

5 tasks

Liryna reopened this Jan 29, 2022

Liryna closed this as completed Feb 15, 2022

onexzero mentioned this issue May 21, 2022

Requset support for DOKAN_CHECK_INTERVAL adjustable. #1094

Closed

5 tasks

insufficient system resources exist to complete the requested service #1058

insufficient system resources exist to complete the requested service #1058

Comments

onexzero commented Jan 29, 2022 • edited Loading

Environment

Check List

Description

Logs

Liryna commented Jan 29, 2022 • edited Loading

onexzero commented Jan 29, 2022

onexzero commented Jan 29, 2022

Liryna commented Jan 29, 2022

onexzero commented Jan 29, 2022

Liryna commented Jan 29, 2022

onexzero commented Jan 29, 2022

onexzero commented Jan 29, 2022

Liryna commented Jan 29, 2022

onexzero commented Jan 29, 2022

onexzero commented Jan 29, 2022

onexzero commented Jan 29, 2022

Liryna commented Jan 29, 2022

onexzero commented Jan 29, 2022

Liryna commented Jan 30, 2022

onexzero commented Jan 30, 2022

onexzero commented Jan 30, 2022 • edited Loading

Liryna commented Jan 30, 2022

onexzero commented Jan 31, 2022

onexzero commented Jan 31, 2022 • edited Loading

onexzero commented Jan 31, 2022

onexzero commented Jan 31, 2022

Liryna commented Jan 31, 2022

onexzero commented Jan 31, 2022

Liryna commented Jan 31, 2022

onexzero commented Jan 31, 2022 • edited Loading

onexzero commented Jan 31, 2022

onexzero commented Feb 9, 2022 • edited Loading

onexzero commented Feb 9, 2022 • edited Loading

Liryna commented Feb 14, 2022

onexzero commented Feb 14, 2022 • edited Loading

Liryna commented Feb 14, 2022

onexzero commented Feb 14, 2022

Liryna commented Feb 14, 2022

onexzero commented Feb 14, 2022

Liryna commented Feb 15, 2022

onexzero commented May 19, 2022 • edited Loading

Liryna commented May 19, 2022

onexzero commented May 20, 2022

Liryna commented May 20, 2022

onexzero commented May 20, 2022

Liryna commented May 20, 2022

onexzero commented May 20, 2022

onexzero commented May 20, 2022

onexzero commented May 20, 2022

onexzero commented May 20, 2022 • edited Loading

onexzero commented May 21, 2022

onexzero commented May 21, 2022

Liryna commented May 21, 2022

onexzero commented May 21, 2022

Liryna commented May 22, 2022

onexzero commented May 23, 2022 • edited Loading

onexzero commented May 23, 2022 • edited Loading

Liryna commented May 23, 2022

onexzero commented May 24, 2022 • edited by Liryna Loading

The attempt to improve response time by reducing DOKAN_CHECK_TIME and Timeout was based on the following log. Results are already at #1058 (comment)

onexzero commented Jan 29, 2022 •

edited

Loading

Liryna commented Jan 29, 2022 •

edited

Loading

onexzero commented Jan 30, 2022 •

edited

Loading

onexzero commented Jan 31, 2022 •

edited

Loading

onexzero commented Jan 31, 2022 •

edited

Loading

onexzero commented Feb 9, 2022 •

edited

Loading

onexzero commented Feb 9, 2022 •

edited

Loading

onexzero commented Feb 14, 2022 •

edited

Loading

onexzero commented May 19, 2022 •

edited

Loading

onexzero commented May 20, 2022 •

edited

Loading

onexzero commented May 23, 2022 •

edited

Loading

onexzero commented May 23, 2022 •

edited

Loading

onexzero commented May 24, 2022 •

edited by Liryna

Loading