Kaseya Community

Not enough storage is available / The paging file is too small for this operation to complete (Win10 Creators Update)

  • We're seeing this issue on many of our machines now that they have converted to Creators update.  I know this isn't a Kaseya issue but we're at a loss as to what is causing it and how to correct it.  The symptoms are that SystemInfo and WMI don't work, so the Audit in Kaseya also comes back blank

    select * from ksubscribers.dbo.vmachine where productname = ''

    Obviously rebooting the machine causes the audit to work again for roughly 2 weeks.

    You'll see the first message (Not Enough Storage is available to complete this operation) - in our experience if you kill MicrosoftEdgeCP.exe (which is usually using 4-5GB of ram) - then you start getting the (The paging file is too small for this operation to complete) message.

    Any help would be greatly appreciated!

  • that's a really weird thing and I've not heard of any similar issue. We've got just over 1,000 Win10 machines on the Creators Update, so that's a good sample size. The process is connected to the Edge browserr which is hardly used at all by our techs. So, you use the Edge browser and let it run without shutting it down, I think. IE and Chrome will also eat up a lot of your memory if you do that, day after day.

    One other option might make a difference, we normally disable fastboot, since that has caused us many a headache in the past. Having a fast starting machine is nice, I understand, but since disabling fastboot with an Agent Procedure, we didn't get a rise in complaints machines were slow starting up. We get stable machines and good general performance and Patch Management, KAV updates will be smoother as well.

  • Thanks!  We disabled fast boot on our image when Win10 came out because of all the problems it causes.  The weirdest thing is - this only seems to be affecting the OptiPlex 3010/3020/3040/3050 and 9020 machines.  I don't see it happening at all on any of our machines and we have 250+ different models running windows 10.  I was planning to start weekly reboots anyway and that will mask the problem - but I wish I knew what was causing it - it's the same image used on all the other machines and it didn't start until the machines upgraded to 15063.  Usually between us we can find a solution, but this one has us all baffled.

  •  What kind of issue you have with fastboot?

  • One challenge with FastBoot is the reported uptime. Unless you REBOOT, the uptime value keeps growing. We remind our users to reboot when the uptime exceeds 14 days, and nag them daily after 21 days. Users were shutting down to take their laptop home at least twice a week but were still getting notices pop up about excessive uptime.

    It's sort of a mini-hibernate of just the OS, so really, you aren't clearing things out on a regular basis by shutdown/power-on. Only the REBOOT action actually clears anything. Disabling FastBoot has eliminated a large number of "weird"  issues. Nobody has ever noticed the difference between FastBoot on or off, so we turn it off by policy.


  •  How do you do that via policy. You created script to do that?

  • HUGE Props to "Steve" at Microsoft for after hours of debugging and tracing found the following was causing the problem:

    Trend Micro has a user-mode hooking DLL (tmmon64.dll) which is intercepting calls to the heap memory allocation functions by overwriting their entry points with jumps to Trend Micro’s code, later jumping back into the heap functions after their entry point.  In one of the traces he saw the flags passed to the heap allocation functions eventually contained a value which was not expected and resulted in the heap manager treating the allocation as a heap manager internal operation along with disabling serialization of the heap.  After this happened the out of memory errors began as allocations could not be found to satisfy the requested blocks of memory.  The heap in question is the main process heap shared by many components running on different threads which means that serialization must remain to prevent corruption of the heap and free lists.  Additional details about the HEAP_NO_SERIALIZE flag can be found in the remarks section of the following article.

    Enabling or disabling User-Mode Hooking (UMH) in OfficeScan (OSCE)


    I have a strong dislike for Trend Micro already - so this didn't surprise me...