SetupFailure stopcode (BSOD) upon updating from 23H2 to 24H2. What failed?

Please advance to post #18, step #5.

There's a problem: I've done the chkdsk C: /b /v while rebooting (no other drives will be connected during the update to 24H2), I've recovered the report manually from the Event Viewer (I haven't needed the *.bat but thanks) and it's in Spanish, very bad Spanish with non intelligible parts. I've done an automatic translation into English (using the Google translator) hoping that someone more familiar with the chkdsk's parlance can interpret it. I'm posting here the original Spanish and this translation into English. I've preceded the latter with the following own note:

(translated automaticly from extremely bad Spanish, not always intelligible, by a not perfect tool; I have corrected a few obvious errors, for instance "disco" was translated to "album" instead of "disk"; I fear some of this translation isn't intelligible in English either but, although I understand chkdsk's parlance when I read it, I'm not familiar enough with it to "generate" a genuine chkdsk report in English)

Is this enough or do I change the display language and redo it? The problem I see to this: chkdsk /b /v has done corrections and the report won't be the same, in theory it should be all okay now in the file system.

I've installed and run HDSentinel w/o hassles. Drive F: is a pendrive where I'm storing the files of this, I'll detach it before doing the 24H2 update. I'll also uninstall the tools still installed for these tests, HDTunePro GSmartControl and HDSentinel, unless there's a good reason against.

Please post a new V2 share link into the newest post.


Windows ha hecho algunas correcciones en el sistema de archivos.


Windows has made some fixes to the file system.

In the middle I've updated the Intel Graphics drivers (at booting I saw a notification about a new update available and I launched "Intel Driver & Support Assistant", what did the install in some few minutes and a reboot, this happens some 3-4 times per year).

Please post a new V2 share link into the newest post using English as the default language.

I had forgotten it completely, sorry.

I'm posting two links to the same file because for some unknown reason, Google drive has changed the links from "usp=sharing" to "usp=drive_link" when I tell it to give access to anyone with the link.

"drive_link version of the link" (original one this time for unknown reasons)


"sharing version of the link" (manually returned to what I know it works, I found a page stating that these modifiers can be changed manually)

There are remnants of checkpoint.

1) See if there is a checkpoint uninstaller to clean all remnants.


2) Run through this list of quick fixes:





3) Create a new folder on the desktop



4) Download to the new folder:





5) Place the computer into clean boot:




6) Perform an in place upgrade repair while in clean boot:

I'm working w/o hurrying in the latter advices, I'm doing progresses.

-------------------------------

In this thread's OP I said I had possibly deleted, accidentally, crucial info or logs to see what had happened in a previous attempt that had failed apparently with the same pattern. This time, I had saved the C:\$WINDOWS.~BT folder generated in case it's relevant. Following this article How to Fix "What Needs Your Attention" Windows 10 Setup Errors I've found... exactly the same as described in the article!!!! The article shows an example where these two things were to blame:

Microsoft Print To PDF
Microsoft XPS Document Writer

(copy-pasted from the article) ...and following the same method (locating lines with 'BlockMigration="True"' in a given section of the latter CompatData_<date>_<time>_<hexCode>.xml produced in C:\$WINDOWS.~BT\Sources\Panther (*) , and following the involved *.inf file(s) clue in C:\Windows\INF ), in my case it's:

Microsoft Print To PDF
Microsoft XPS Document Writer

(copy-pasted from my *.inf files; in the article the involved files are oem80.inf and oem81.inf , in my case they're oem86.inf and oem87.inf , but this difference doesn't look significant)

(*): two things: the article's file names include "_3" between <time> and <hexCode> that isn't in my file names, and the "discrepant" lines in both cases (the article's file and my file) don't only differ from the others in 'BlockMigration="True"' (instead of False in the others), but also in 'HasSignedBinaries="False"' (instead of True in the others), a difference that I consider more relevant given the nature of this (although imo 24H2 or any other OS update or OS shouldn't care about this: an OS is like a road, vehicles with flaws might have problems but the road shouldn't be designed to autodestroy itself if such a vehicle uses it, the problems should be treated individually for each vehicle; 23H2 is working fine with these and other "flaws", what's the problem then???? ).

-------------------------------

Does anyone have experience with this? Regardless of difficulties in other areas like my security app (that was badly installed at best), does this method point to actual culprits? (I mean, let's suppose I've never ever touched a dubious hw or sw in my entire life, does this technique identify two actual causes of failure that will impede any attempt until I fix precisely them, no matter how much "clean" and 24H2-ist is the rest of my system?)

So I know at least two systems where these two precise items have caused difficulties/impossibility to update. The article doesn't even mention Windows 11, it's about Windows 10 but we all know they have a lot in common. Are these items "well known" (to say it some way) in making OS updates fail?