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?