Update Version 1803 to 1809 Consistently Gets Error 0xc1900101

I only selected three flags, the ones recommended in the generic post about BSODs. ALL non-Microsoft drivers are selected. I did NOT click "Add currently not loaded driver(s) to the list" which I was thinking that we might look at. Results of /querysettings:

Microsoft Windows [Version 10.0.17134.799]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\Data>verifier /querysettings

Verifier Flags: 0x00000610

Standard Flags:

[ ] 0x00000001 Special pool.
[ ] 0x00000002 Force IRQL checking.
[ ] 0x00000008 Pool tracking.
[X] 0x00000010 I/O verification.
[ ] 0x00000020 Deadlock detection.
[ ] 0x00000080 DMA checking.
[ ] 0x00000100 Security checks.
[ ] 0x00000800 Miscellaneous checks.
[ ] 0x00020000 DDI compliance checking.

Additional Flags:

[ ] 0x00000004 Randomized low resources simulation.
[X] 0x00000200 Force pending I/O requests.
[X] 0x00000400 IRP logging.
[ ] 0x00002000 Invariant MDL checking for stack.
[ ] 0x00004000 Invariant MDL checking for driver.
[ ] 0x00008000 Power framework delay fuzzing.
[ ] 0x00010000 Port/miniport interface checking.
[ ] 0x00040000 Systematic low resources simulation.
[ ] 0x00080000 DDI compliance checking (additional).
[ ] 0x00200000 NDIS/WIFI verification.
[ ] 0x00800000 Kernel synchronization delay fuzzing.
[ ] 0x01000000 VM switch verification.
[ ] 0x02000000 Code integrity checks.

[X] Indicates flag is enabled.

Boot Mode:

Persistent

Rules:

All rules are using default settings

Verified Drivers:

tcesd.sys
amd_sata.sys
amd_xata.sys
asahci64.sys
dkdfm.sys
file_tracker.sys
dktlfsmf.sys
fltsrv.sys
volume_tracker.sys
symefasi64.sys
snapman.sys
ccsetx64.sys
ironx64.sys
symevent64x86.sys
srtsp64.sys
srtspx64.sys
tcefs.sys
symnets.sys
idsvia64.sys
eectrl64.sys
eraserutilrebootdrv.sys
bhdrvx64.sys
asupio.sys
asio.sys
gearaspiwdm.sys
aichargerplus.sys
asmtxhci.sys
usbfilter.sys
rt640x64.sys
rtkvhd64.sys
asmthub3.sys
lhidfilt.sys
agrsm64.sys
wdcsam64.sys
dump_diskdump.sys
dump_amd_sata.sys
dump_dumpfve.sys
file_protector.sys
mbamchameleon.sys
virtual_file.sys
tib_mounter.sys
mbamswissarmy.sys
dkrtwrt.sys
mwac.sys
mbae64.sys
mbam.sys
farflt.sys

C:\Data>

Please increase the number of customized tests by 4 - 5 / hour up to the nineteen in this link:
https://answers.microsoft.com/en-us/...3-c48669e4c983

Find a flash drive that you can format (> or = 8 GB)

Create a bootable windows 10 iso:
Download Windows 10 ISO File
https://www.microsoft.com/en-us/soft...load/windows10

Boot to the iso > open the windows advanced troubleshooting menu on the iso > open command prompt > type: verifier /reset > reboot > if this fails then type: verifier /bootmode resetonbootfail > reboot > if this fails the system restore starting with the oldest restore point and keep repeating as necessary to the most recent restore point > if this fails then restore the acronis backup image > if this fails then perform a custom install > if this fails then backup all important files to another drive using a bootable Ubuntu flash drive

For any BSOD:

a) run the V2 log collector to collect new log files

b) open file explorer> this PC > C: > in the right upper corner search for: C:\Windows\memory.dmp
> if the file size is < 1.5 GB then zip > post a separate share link into the thread using one drive, drop box, or google drive

Restored from Acronis backup, running on Windows again now. Running sfe and dism, then WU. The WU database seems empty; no update history. May run Update Troubeshooter wu10.diagcab.

Yes, you are gentle but I did it to myself, by enabling all 19 checks instead of following your instructions to add a couple at a time. I just finished rebooting from v1803 update KB4499183. That's the only entry in the update history.

I'm going to continue a few checks and uninstall some old software that I don't use anymore before I run verifier again, which will be tomorrow afternoon. Which checks do you suggest that I start with?

The three customized tests in the Ten Forums link did not produce any BSOD. You can start with these to get in rhythm. Then you can add and remove in any method that makes it easy to keep track of the customized tests. With a lot of software drivers, performance and boot may be impacted more with each customized test. So you can add one at a time every 15 minutes and run no more than eight or nine total customized tests at any one time. The impact on performance and boot is unknown and is trial and error.

OK, that sounds like a well-considered strategy, with announced unknowns and risks. I need to bring my ongoing data up to date from my other machine and make a new Acronis backup and restore point. System is a bit clunky; Diskeeper needs more time with it, I think.

If there were a memory map that the exception processor could use with the stack, a walkback could be made part of the BSOD logs and we would have much less need of low-level debugging tools like verifier. Apparently the overhead of maintaining a real-time memory map is a problem; perhaps keep it in RAM, not on HD? Make the real time walkback stack a boot option, like verifier hooks?

Now that the true risk of using verifier has reared its ugly head, I'm wondering is there is a worse way to find a shaky driver without the risk. I suspect not, because if there were, we would not be down this path, but, just asking.

There are three main options for finding misbehaving drivers:
1) debug spontaneous mini dump files
2) debug spontaneous memory dump files
3) use windows driver verifier to create dump files for debugging

There are pro and con for each:
For mini dumps the log files can be collected and debugged by software or websites that only run one command.
It's quick but there are bugchecks that need to be debugged as memory dumps to run more commands and find the misbehaing drivers or malfunctioning hardware.
Memory dumps take a lot of time to upload, download, and debug.
Windows driver verifier shortens the time period by creating dump files.
And the tool creates new types of dump files, making some more complex dump files easier to debug.

Ordinarily, only system restore is used as the third backup option (method to turn off or recover) when running windows driver verifier.
See both the Ten Forums and Microsoft links.
Making backup images was/is an extra backup layer.