Windows 10 1903 Scheduled Task causing network Filter Driver Filter Reset

Hello OSR,

Has anyone else noticed that on the new Windows 10 1903 Builds (Win 10 Professional), that a Scheduled Task (\windows\system32\provtool.exe /turn 5 /source LogonIdleTask) is forcing a network stack reset?

Our NDIS Lightweight Filter Driver is running into issues from this Scheduled Task, since the task triggers a FilterReset() on the driver. Our users are usually actively streaming packets from our device by the time the scheduled task runs, causing failures. The filter driver resets and the user loses connection to the device. In fact, they usually have to re-enable the NIC to restore functionality. We were able to manually run the command line and produce the same failure state as waiting for the scheduled task to trigger.

Does anyone have information on what the Provtool does, especially the /turn 5 and /source LogonIdleTask? I have seen others reference the same command line elsewhere. This issue is new to Windows 10 1903 build (at least, between 1803 and 1903). Looking for any advice/similar experiences.

Thank you,
Tim

By “FilterReset” do you mean FilterPause + FilterRestart?

Contractually, NDIS permits itself to pause the datapath at any time, for any reason. A driver needs to continue working correctly if the datapath is briefly paused.

I understand, though, that pausing the datapath can be disruptive to traffic that’s sensitive to milliseconds of latency, so NDIS won’t pause without some good reason. Since NDIS is just a middle-man, it doesn’t really ever initiate things itself; all the pauses come from external forces, like installing a new driver or some other driver calling NdisFRestartFilter. You can get some idea of which external force is causing the pause to happen by looking in NDIS’s wpp traces.

I don’t know much about provtool.exe myself, but I poked around a bit and it seems to be a generic tool for manipulating device policies (aka MDM). So perhaps there’s some device policy in your organization that involves some OS component that for some reason needs to pause + restart the datapath. I’m not sure; it doesn’t repro on my own machine.

One guess: I think we support a network-qos policy, which might conceivably cause the Psched driver to do the pause + restart. Does stopping psched (net stop psched) fix the problem? If so, you have to make a choice between getting the QoS features that your organization apparently wanted, and avoiding the blip in the network while those QoS features are installed.

Thanks for the response and information. I did mean FilterPause+FilterRestart, instead of FilterReset. Thank you for the NID WPP tip, and the relation with MDM.

This Scheduled Task restarting the filter driver was noticed by a customer that kept seeing their product’s device stream dying ~10-30 minutes into booting up Windows. After lots of work, they narrowed the culprit to something firing off in Task Scheduler (specifically Task Scheduler Library\Microsoft\Windows\Management\Provisioning\Logon), and further found the provtool.exe one-liner that repros it (if you run it before the ~30 timer, since the pause+restart only happens the first time the task/provtool is run). I suppose the reason it is ~10-30 minutes is because task scheduler defaults to ‘Start the task only if the computer is idle for: 10 minutes’

The customer consistently repros the issue across all their products, since they burn the same Windows 10 1903 ISO image into each of the PC’s they ship. (They recently upgraded their image from 1803 to 1903).

I thought similarly to you; since they know the task that causes the issue (and they assume the task has to be run, since Windows scheduled it ‘for a reason’), maybe the simplest solution is to manually run the provtool before starting our filter driver/streaming device? But they are adamant to leave the task alone, which gives me the task of trying to make sure the device stream can ‘survive’ the pause/restart process- which I suppose can be done as long as i mange the datastream properly; though I don’t see how I can capture packets lost during the filter being paused.

Quick followup question on my own statement:

I suppose the reason it is ~10-30 minutes is because task scheduler defaults to ‘Start the task only if the computer is idle for: 10 minutes’

Can you see any issue with choosing to run this provtool command first, rather than ‘after the computer is idle for 10 minutes’? If i can convince the customer that it is okay to manually run this first and not until after the rest of the user-software is booted up, it would provide a much quicker resolution.
Thanks,
Tim

Can you see any issue with choosing to run this provtool command first, rather than ‘after the computer is idle for 10 minutes’?

I don’t know anything about MDM or provtool.exe… I’m just a janitor in the drivers department. In general, if this task was just added in the most recent release, it seems likely that it could be further refined in the near future, so you can’t assume that the parameters will always be the same, unless there’s documentation that promises the parameters will remain the same.

The most robust solution would be to make your driver robust against short pauses. There will be other situations that cause a pause+restart, aside from provtool. So even if you spend a lot of time wrangling provtool into submission, your next customer might come along and say “every time I update my antivirus software, there’s a disconnect in the datastream…”.

Sounds good, thanks Jeffrey. I’m definitely looking into robustifying the driver on my end. Your feedback has been very helpful, thank you!