Discussion: 22H2 Task Scheduler Bug

Hellbovine

Hellbovine

Well-Known Member
Update: September 1st, 2023 (Unresolved)

This post explains about a bug that affects the Task Scheduler in Windows 10 and 11, version 22H2. I discovered that a bug prevents the scheduler from properly finishing its tasks, which means it continues to run forever and consumes extra resources, while many of the tasks fail to ever initiate and perform their duties. AeonX later found the culprit (link1) and Microsoft silently fixed this bug in an unknown update.

The problem though, is this continues to be an issue for people that rely on the ISO images that Microsoft releases at the end of every year (link2, link3) because those builds remain unpatched until the web page is updated for the next version. In other words, these links still provide the broken task scheduler build for 22H2, and it will not be fixed until they are replaced with the 23H2 version that will release somewhere around November of 2023. This thread remains relevant and in "unresolved" status until Microsoft replaces their broken builds.

To complicate this, Microsoft made things more difficult for users that try to download older Windows. They have begun deleting links to older versions, and this is causing all the third party sites and tools which relied on those, such as Rufus, to lose the ability to provide users with those downloads now. As such, most places only offer the Media Creation Tool (MCT) or the links to the Microsoft page that I included above.

If you need a copy of Windows 10 21H2 (the most popular and stable choice between W10/W11 and all their versions at this time) you can get it using a guide (link4) I made, or by exploring the other options in that thread. Users should expect that these workarounds will eventually be disabled by Microsoft too, especially when they really start to address the BlackLotus UEFI issues in the year 2024, which is discussed more in that thread.

ORIGINAL POST
Heads up for anyone looking at using Windows 22H2, there seems to be an undocumented bug I just discovered, which prevents the Task Scheduler from properly finishing its tasks. In my opinion this build is unusable without a fix, as this is a critical component. Below is how to replicate the issue:

- Download an unmodified ISO from Microsoft for W10 or W11 22H2
- Mount ISO, copy/paste files onto the root of a freshly formatted USB drive
- Unplug internet to avoid automated updates which may interfere
- Boot to USB and install Windows

Once you reach the desktop, wait about 5 minutes for initial background activity to subside, then once you reach the desktop run this bat file:

@ECHO OFF
ECHO Running Task Scheduler
ECHO This may take 30 minutes or more to finish.
%windir%\system32\rundll32.exe advapi32.dll,ProcessIdleTasks
ECHO.
ECHO Task Scheduler Finished!
ECHO You may now reboot your computer.
PAUSE

It takes 15-30 minutes and the command prompt will disappear once the Task Scheduler finishes. The reason I use a bat file is because this way I have an indication when it is done, otherwise it is difficult to track. If it finishes, reboot, and you'll have lower task manager resource usage because all the background processes have had a chance to complete their pending activity. I was doing this because I wanted to benchmark 22H2 vs 21H2 and to test this build out to see if it was worth updating my guides to use it.

The problem though, is Task Scheduler bugs out and never finishes, it continues to run forever. I tried this twice now. First, I let it run for 4 hours before canceling it, then I did another clean format/install and let it run for an hour before canceling that. A clean install of 21H2 does not have this problem. I already submitted a report to Microsoft, but if others can replicate it then we really need everyone to report it because this is a serious bug.
 
Last edited:
I'm now wrapping up a 3rd test where I've connected to the internet and ran the bat file, to see if it's getting botched due to some online requirement that was added, but it's looking like this one will fail too. I'll also try without using NTLite, to see if that is causing a problem.
 
Last edited:
When you disable networking, OOBE ZDP and WU updates don't happen.

"rundll32.exe advapi32.dll,ProcessIdleTasks" forces scheduled tasks that only run when the system is idle to kick off. There's ZERO system optimization involved, you're just telling Windows to run resource-intensive background tasks NOW, instead of waiting for idle time.

How does that temporarily improve system performance, other than a task has some minimum backoff, not running itself again within a certain time period? Is that different that disabling all those tasks from running at all?

I don't doubt there's a change. But what ARE you actually measuring?
 
I get the devil's advocate approach, but inevitably it's going to cause the thread to derail into everyone's opinions about how they use Windows. It's not that I don't appreciate these discussions, but they can get carried away at times and substantially off topic. At the moment I just want to figure this bug out so it can be reported and fixed, and frankly everyone here should be concerned because it is a performance problem.

To quickly answer most of your questions, not everyone wipes their task scheduler empty with NTLite, because not all of us blindly delete everything without knowing the consequences. Running this command does in fact lower the threads/handles/processes afterwards, which is easy to verify yourself, and has been documented by Microsoft as well as overclocking and benchmarking sites.

Task Scheduler covers a wide range of things, it carries out everything from defrag and trim, disk cleanup, Windows Updates, .NET framework optimization, and so much more. There's over 100 different tasks it runs through, so to say "zero optimization" is plain wrong. I didn't say it was going to increase frame rates or something else inaccurate.

The point of this command is to force Windows to run through everything it has on its pending to-do list, update the registry (nearly 3,000 changes are made), and to calm the OS down for a bit so that there is less chance of something interfering with my tools and data. That's how proper testing and benchmarking is done, with a clean environment that eliminates as many variables as possible.
 
Last edited:
Just finished my last test method. I tried 4 different approaches in total, and it bugs out on all of them. To clarify, Task Scheduler on my older hardware takes about 30 minutes to finish on W10 21H2, and for the first test of this 22H2 version I let it go for 4 hours before stopping it, and the other tests I let them go for 1 hour before aborting.

For the final test I did everything the way Microsoft expects people to do it, which meant I kept my internet online during Windows Setup, which allowed it to install a KB update that still didn't fix this issue, and even after treating the operating system like a fragile baby and giving it ample time to finish contacting the microsoft servers, activating my license, etcetera, I rebooted and tried the batch file, and it still bugs out.

The processes/threads/handles are also much higher than they should be for 21H2 versus 22H2, which is likely due to this Task Scheduler bug. Furthermore, once I reach the desktop after Windows Setup is done, it also bugs out my network connection and I lose internet. To fix that I have to go into my adapter properties and manually set my IP address since Windows is failing to use DHCP properly.

This is clearly a broken ISO release from Microsoft, unless other people try it and just don't have these issues, but I can't see how that would happen. I'm heading out for the night, I'll check in tomorrow and see if anyone tried this.
 
Last edited:
Hellbovine said:
Heads up for anyone looking at using Windows 22H2, there seems to be an undocumented bug I just discovered, that prevents the Task Scheduler from properly finishing its tasks. In my opinion this build is unusable without a fix, as this is a critical component. I confirmed it in W10 so far, and have no plans to test W11 since I don't use that OS.

How to replicate the issue:
- Download a clean, unmodified ISO from Microsoft for W10 or W11 22H2.
- Mount ISO, copy/paste files onto the root of a freshly formatted USB drive.
- Unplug internet (optional).
- Boot to USB and install Windows.

Once you reach the desktop, wait about 5 minutes and if you are online it will download a display driver automatically. After the driver is installed and initial background activity has subsided (if you are offline you can proceed without the driver), reboot, then once you reach the desktop again wait another minute and then run this bat file:
@ECHO OFF
ECHO Running Task Scheduler
ECHO This may take 30 minutes or more to finish.
%windir%\system32\rundll32.exe advapi32.dll,ProcessIdleTasks
ECHO.
ECHO Task Scheduler Finished!
ECHO You may now reboot your computer.
PAUSE

It should take between 30-45 minutes and the command prompt will go away once the Task Scheduler works through all 100+ tasks. The reason I use a bat file is because this way I have an indication when Task Scheduler is finished, otherwise it is silent in the background and more difficult to track. After it finishes, reboot, and you'll have lower task manager resource usage because all of the background processes have had a chance to complete their pending activity. I was doing this because I wanted to benchmark 22H2 vs 21H2 and then test everything out in this new version so that I could update my guides.

I tried this twice now. First, I let it run for 4 hours before cancelling it, then I did another clean format/install and let it run for an hour before quitting. A clean install of 21H2 does not have this problem. Is there anyone on either W10 or W11 that can do a clean install of 22H2 and see if they can replicate this? I already submitted a bug report to Microsoft, but if others can replicate it then we really need everyone to report it because this is a serious bug.
Click to expand...
Having windows 11 and probably never leaving it on long enough in idle maybe a wise thing to do for me however since I stopped all updates till 2024 wouldn't this force my windows to update again which I don't want to do at the moment?
 
Looks like Microsoft acknowledged this (link) and it won't be investigated until January due to the holidays.
 
Last edited:
That thread quotes a MS support vendor (not a real employee), and is standard boilerplate. The normal "lockdown" season for MS extends from Thanksgiving to the New Year -- nobody's in the office. It's a real seasonal thing in Redmond.

But it doesn't actually acknowledged the bug report. Support guy is just giving a true, if uninformed reply.
 
garlin said:
That thread quotes a MS support vendor (not a real employee)...Support guy is just giving a true, if uninformed reply.
Click to expand...
I just saw "Microsoft Agent" and "Moderator" tags, and assumed he would be reporting it. Actually, the reason I didn't see this thread before I posted here with my findings was because I've gotten into the habit lately of blocking answers.microsoft.com from my Google searches, because I got so sick of seeing thousands of threads from customers with problem where every "solution" is stupid and plays out as follows...

Customer: I opened my front door and my dog ran away!

Independent Advisor: Hello, I understand that you are experiencing difficulties in Windows. I am an Independent Advisor and will try to assist you. I believe this can be fixed by opening up a command prompt and typing: sfc /scannow

That is literally the answer for 99% of all posts on that forum. These advisors clearly don't know much about computers, and all of them go to SFC as if it's a god tool that fixes everything. In my 30 years on computers I've used SFC to actually fix anything, nor would I ever recommend it.
 
Last edited:
"Hi. I'm Greg, 10 years awarded Windows MVP, here to help you."

I won't actually try to figure out YOUR specific case, but here's a list of unhelpful links. My success rate is about the same as other MS support agents. Even a blind squirrel finds a nut once in a while...

sfc /scannow is the knee-jerk answer on all BleepingComputer, and half of Ten/ElevenForum questions. Of course, NTLite's answer is "start over with a clean ISO".
 
Interesting, I have a VM on VMware with Windows 10 Pro 22H2 build 19045.2251 (November 8, 2022).

Running the test now :)

As I typed here the .bat finished in 7 minutes.

In this VM I made some tweaks, disabled diagtrack service and scheduled tasks related to telemetry and disabled Defender, Windows Update, Windows Error Reporting and CEIP with group policy.

It seems that some task must be causing this problem, I noticed that the task that took the longest to finish was \Microsoft\Windows\Maintenance\WinSAT so it may be that some of the tasks never finish.

EDIT:
I will repeat the test without any tweaks on the official Win10 22H2 January 2023 ISO.
 
Last edited:
Well, I tested it on VMware now with Windows 10 Pro 22H2 build 19045.2486 (January 10, 2023).

The bat file now finished in 20 minutes, it probably took longer because Defender was enabled.

The task now that took longer to finish was \Microsoft\Windows\Windows Defender\Windows Defender Scheduled Scan

I installed Windows without internet and I didn't connect to the internet at any time. Waited 5 minutes which is when OneDrive finished installing, I didn't modify anything nor did I disable OneDrive lol
1674279521114.png

Then I restarted and waited another 5 minutes for the CPU usage to stabilize (lots of apps run in the background and then disappear). Then I ran the bat file.

I have not installed VMware Tools. I included the bat file in an ISO and mounted it on the VM. I'm going to do another test with VMware Tools installed and connected to the internet, disabling the WinSAT and Windows Defender Scheduled Scan tasks to save time, but I think the result will be similar.

Despite the bat file finishing I noticed that an Edge task is still running, it is probably trying to update Edge but there is no internet. Therefore a test with an internet connection will be interesting.

I suggest testing with an ISO updated with the January 2023 updates or with some recent cumulative update and if it gets stuck without finishing you can check which tasks are running with the following command:

Code: 
SCHTASKS /Query | find /i "Running"
 
AeonX said:
Well, I tested it on VMware...
Click to expand...
I'm suspecting that the VM is why you're not seeing the same result I did. There are a number of things that behave differently in a VM versus a real install, which would also explain why Microsoft missed this, because they do all their work in a VM now in recent years (link1).

The ISO I used was straight from Microsoft, and was released in October I believe it was (link2). Since you're testing different builds, I'm guessing you must be pulling those from uudump or something? Try the one from Microsoft instead, and in a non-VM. I had zero modifications made to the ISO, I just installed it as-is from Microsoft so the problem couldn't be any tweaks I did or anything like that.

I think what's happening, is some task(s) have a permissions issue and cause Task Scheduler to then bug out when it reaches that task. Once it bugs out it stops going down the remaining list items and sits there, running forever until a reboot. I replicated it 4 times, all clean installs which included deleting previous partitions (no repair, no upgrade, no VM). I can't see any other reason why it would have consistently failed. I also grabbed the unmodified 21H2 ISO I had saved on a USB and installed that just to be sure, and it worked perfectly.
 
Last edited:
Hellbovine said:
Since you're testing different builds, I'm guessing you must be pulling those from uudump or something?
Click to expand...
I download ISOs updated monthly by Microsoft from the SVF Repository in MDL. I had the November 2022 ISO but I recently downloaded the January 2023 ISO and deleted the older ones. So there was no way to do a clean install with the same build. But it makes the same download from the Microsoft website and update to the latest cumulative update. Did you try to update? Microsoft may have silently fixed this.

Hellbovine said:
Try the one from Microsoft instead, and in a non-VM.
Click to expand...
I have no way to test it on a real machine at the moment. I don't have a test machine, only my desktop here runs Windows 10 fine and I can't do a clean install right now. That's why I tested it in VM. But the only difference will be the drivers installed, so it's important to try to debug and find which task is causing this, whether it's a task related to some installed software or even drivers.

It would be easier to replicate the problem by knowing exactly which task causes it. Anyway if I manage to do a clean install for these days I'll see if I can test it.

PS: I think I released the monster!! After connecting to the internet a lot of glitter appeared on the VM, does Microsoft now make OS for Barbies? after updating Edge even closing it continues running in the background, WTF?? Microsoft can be more annoying than Google. Good thing we have nuhi to save us.

PS2: OK, I'll download the ISO from the Microsoft website and see if it's possible to replicate the bug in a VM.
 
Last edited:
Check out the Microsoft forum topic too (link1), it has a lot of extra insights about the issue. These guys are complaining about manually created tasks failing, and that's why they all noticed the problem. What I saw was much bigger, because I ran that idle tasks command, which most people don't do, and even fewer people would run it in a batch file which allowed me to easily see that it's failing.

Tomorrow I'll download one of the builds you used and install it in a non-VM to check and see what happens and report back, but all those guys in the Microsoft forum still have the issue, and there's no mention of task scheduler anywhere in the 22H2 "Known Issues" or "Resolved Issues" lists (link2), probably because they're still scrambling to fix all the other problems that have arisen from this update (link3).
 
Last edited:
lol
1674285650417.png

It must have been some component I removed, probably BITS service.

Do you know which build exactly is causing the bug? I'll have to download this some other way.

Hellbovine said:
Check out the Microsoft forum topic too (link)
Click to expand...
I'll give it a read and see if I can find a way to replicate this.
 
If you use a non-Windows device to visit their ISO page it won't force the Media Creation Tool (MCT) on you. A trick is to change the user agent in your browser to something that's non-Windows and once the webpage detects this it refreshes and provides the ISO file for direct download.
 
Last edited:
Hellbovine said:
If you use a non-Windows device to visit their ISO webpage it won't force the media creation tool on you, or instead, you can change the user agent in your browser to something that's non-Windows. If the webpage detects this, it updates and provides the ISO instead of the tool.
Click to expand...
I never downloaded ISO there, I didn't know about that trick I'll try that.
 
You must log in or register to reply here.
Back
Top