-
Nope, both PC’s are running Windows 10 Pro 22H2!
Seems pretty obviously that one of my custom Group Policy, Registry and/or Services settings is why the update didn’t create that folder.
IMHO, if a “user” can set something that prevents it from being created, that calls into question Microsoft’s assertion it’s purpose is to increase protection.
If that were true, the update should override any such setting and always create the folder!
1 user thanked author for this post.
-
Very strange update result!
I just installed KB5055518 on both of my Windows 10 22H2 PC’s and, unlike what everyone else has experienced, it did not create an empty C:\inetpub folder.
IMHO, this makes the the “highlighted” part of Microsoft’s quote about the creation of that folder suspicious.
[OS Security] After installing this update or a later Windows update, a new %systemdrive%\inetpub folder will be created on your device. This folder should not be deleted regardless of whether Internet Information Services (IIS) is enabled on the target device. This behavior is part of changes that increase protection and does not require any action from IT admins and end users. For more information, see CVE-2025-21204.
1st, if it’s real purpose is to “increase protection“, then why didn’t the update create it on my two PC’s — especially since it did happen on other users PC’s?!?!
2nd, the CVE referenced in that quote indicates the problem is “Improper Link Resolution Before File Access (‘Link Following’)“. So how is having an “empty” C:\inetpub folder (i.e. link that needs to be resolved but no files to access) vs not have it at all (i.e. no link to resolve and no files to access) a better solution??
1 user thanked author for this post.
-
-
or be triggered by, and have a direct correlation with, the .NET Framework cumulative updates (KB5055683)
I’ve installed .NET CU KB5055683, but not KB5055518, and can personally verify it did not create a C:\inetpub folder!
So, as your screenshot of C:\Windows\servicing\Packages indicates, it must have something to do with fact that KB5055518 updates several of the IIS packages.
1 user thanked author for this post.
-
While searching for “AdobeGCClient.exe Missing api-ms-win-core-libraryloader-|1-2-1.dll” I ran across this Update for Universal C Runtime in Windows page containing the following tidbit that explains why a Windows 7 app would need a Windows 10 dll to work.
Microsoft Visual Studio 2015 creates a dependency on the Universal CRT when applications are built by using the Windows 10 Software Development Kit (SDK). You can install this update on earlier Windows operating systems to enable these applications to run correctly.
So the problem seems to be Adobe used the Windows 10 SDK when creating AdobeGCClient.exe, even for older versions of Windows, “assuming” all versions of Windows had been updated with a Visual C++ redistributable package that included the newer dll.
I checked and, unfortunately, the file info for the downloads on that page indicate they only contain Api-ms-win-core-libraryloader-l1-1-0.dll not api-ms-win-core-libraryloader-|1-2-1.dll.
I also checked all the Visual C++ redistributable packages on both my Windows 7 & Windows 10 PC’s and, even though they’re all up-to-date with the most current versions of Visual C++ redistributable available, none of them include the newer version either.
That makes me wonder exactly which update would actually include it and where you’d get it.
Maybe it’s in a specific Visual Studio/C++ SDK?
1 user thanked author for this post.
-
Haven’t yet installed the April updates but…
That folder is part of Microsoft’s IIS (Internet Information Services) and “normally” only gets created if one or more of the IIS features are enabled.
If it’s suddenly appearing after the April update, then either installation of the update requires part of IIS or Microsoft has decided to forcible enable part of it for everyone?
@Susan, suggest you check the IIS features under Turn Windows feature on or off to see if something’s changed on those PC’s.
-
-
Api set api-ms-win-core-libraryloader-l1-2-1.dll was used for only one Windows API function. Even then, that implementation was subsequently changed by Microsoft to relocate that function to a different api set.
If you look at the full list on that Microsoft page, you’ll see 6 different API’s from api-ms-win-core-libraryloader-l1-2-0.dll that were moved to api-ms-win-core-libraryloader-l1-2-1.dll so there’s definitively more than just one API in it!
Also note, all the API’s displayed on that page are ones used by Windows 10 and @IreneLinda is using Windows 7!
Finally, regardless of whether any of the API’s might have been moved into a different version of libraryloader, the error message she’s getting indicates there’s an app installed on her PC that still needs api-ms-win-core-libraryloader-l1-2-1.dll to work.
1 user thanked author for this post.
-
-
Just FYI…
I went thru a similar process when moving an existing local account’s settings from one PC I still use to another one with all the same programs but a different username and discovered it’s actually not as simple as changing the items in your attached pdf file.
There are a lot of other locations both in the registry and individual configuration files used by 3rd party apps where the old username is stored (as a either a string or hex value) that can cause “strange symptoms” when running some OS procedures and/or apps.
Took me a quite a few months of sometimes encountering such problems, sometimes not, before I finally realized that was the culprit by analyzing the error logs when a problem happened.
I then went back and searched the whole registry & all the config files to find and update any instances of the old username with the new one (there were a bunch of them) and all the “strange symptoms” stopped happening.
1 user thanked author for this post.
-
-
-
Except, if you look at the first partition of my drive, it’s a basic data partition.
If you go back and look at the image of your drive setup in your post #2760094 and compare it to the new setup you’ll see the only difference is partition 1 (SYSTEM_DRV) shrank to 1.37GB and there’s now a 100MB partition between it and partition 3 (Tiny C:).
That’s the new EFI partition mbr2gpt created and I believe what’s confusing you is, in the section “above” the graphic presentation, it’s the first item in the list.
However, that doesn’t mean it’s partition 1, it’s listed first simply because, by default, the “Volume” column is sorted alphabetically.
In fact, notice how it’s labeled Disque 0 partition 2 not partition 1!
BTW, glad we were able to help you get it squared away.
1 user thanked author for this post.
-
I only have 3 partitions on the drive, including a logical one for Data (I’ve had a few problems with that PC and after reinstalling Windows a couple of times I don’t have a recovery partition anymore).
Bearing in mind:
The whole reason logical drives were created in the first place was to allow MBR disks to have more than 4 partitions (GPT can have up to 128.)
The fact it appears your drive never had more than 4 partitions (current 3 + recovery.)
Windows treats a logical drive D: and a simple volume D: exactly the same (i.e. like separate drives.)
You didn’t really need to create a logical drive D:, you could have created a simple volume D: instead and achieved the same results to hold your data.
With all that said, the simplest way to deal with your existing logical drive/partition to allow the use of mbr2gpt while keeping all the data it contains is:
1- Make a full backup of logical D:
2- Delete the logical partition
3- Create a new simple volume and assign it drive letter D:
4- Restore the backup to the new volume D:
Now when you run mbr2gpt.exe /validate /allowFullOS the result should be “Validation completed successfully” and you can start the conversion process.
1 user thanked author for this post.
Author
