- This topic has 5 replies, 2 voices, and was last updated 1 year, 1 month ago by .
-
Posts
-
Hello everyone,
I work on an airgapped network consisting of about 50 airgapped Windows 10, 21H2 machines. about 20 of them are 32 bit. The network that I work on absolutely cannot be connected to the internet, under any circumstances.
I’ve had zero issues with patching in the last year, but over the last two months, only the 64 bit machines have been able to receive a patch. the 32 bit machines simply will not patch.
The error code that BatchPatch spits out is “-102: Failed to execute the search. HRESULT: -2147024882”. Converted to HEX, that is 8007000E. According to Microsoft, that simply means that the Windows update service isn’t functioning correctly. I am then advised to do things like rebuilding the ‘Software Distribution’ folder and catroot. None of these solutions have worked for me. Additionally, it is strange that I have about 20 32 bit machines, all with the same issue. It seems unlikely that they all have the same issue with Windows update. I have also tried things like switching the AV off and running BatchPatch locally. Additionally, I discovered that I could install these updates manually right on the machine.
Is there anywhere else that I can look for additional logs or information?
The error is:
0x8007000E -2147024882 E_OUTOFMEMORYIf these 32-bit computers are memory-constrained then you could see if rebooting one and then immediately performing the scan right after that works (before memory gets hogged by anything else on the machines). However, that might not be a sustainable practice.
As a workaround I would suggest that since you are able to manually install the updates directly… just use the BatchPatch ‘Deploy’ feature to deploy those .msi files directly to target computers. This way you can still do it all quickly, and it avoids the scan process that is failing due to lack of available memory.
The offline WsusScn2.cab file is different each month, and it’s possible that each month it has different memory requirements to run. However, it’s also possible that the target OS memory usage increased after applying Windows updates a few months ago. Or maybe you installed some other app on those target systems a few months ago that increased their memory usage? Another option then might be to manually kill apps that are hogging memory before you do the monthly patching.
Well, it’s all relative. 70% of 0 is 0. But 70% of 64GB is ~45GB. So the real question is how much absolute memory is available, not how much percentage is available. I don’t know if adjusting the page file would have any impact or not because 32-bit systems only have a max of 4GB of addressable memory, and the OS is going to be using most of that, and it’s not really clear what’s happening under the hood with the Windows Update Agent that would cause the out of memory error to occur in the first place, and I don’t know the current size of your paging file or if it would change the outcome of what you’re encountering. As for producing reports, I hear ya. You can still see the history report under ‘Actions > Windows update > Generate consolidated report of update history’ so maybe that helps. But also try doing a fresh reboot of a target system and then immediately scanning after it comes back online, and see if that does the trick. Or try evaluating if there are any other RAM hogs that can be killed before doing the scan for updates. Etc.
I doubt that the file size itself is what’s causing the issue. I don’t think it loads the entire file into RAM. Also, the file size has been pretty similar for the past several months. The size cycles over time, so if you look at the historical sizes the way it works is the file size grows each month by a little, and then at some point it’s cut way down, and from there it begins growing a little each month again until eventually it’s cut back down again. The point is that while the file this month is about 800MB, a year ago it had gotten to 1100MB, and you weren’t having problems at that time. Anyway, you’re correct that the size of the file is not something that we have any control over. Microsoft distributes it, and it is what it is.
- You must be logged in to reply to this topic.