new release of Windows 10 reporting bad digital signiture

[whiggs]

Hello forum community.  So I updated to the newest build of Windows 10 a couple of days ago and I began getting an error when attempting to perform Dism /online /cleanup-image /restorehealth commands (even with the /source and /limitaccess arguments specified) that the source files could not be found.  In an attempt to fix, I ran Windows AIO app in safe mode, and found that, during the pre-scan, the following package file was found to have a bad digital signature:

C:\Windows\servicing\Packages\Microsoft-Windows-TestRoot-and-FlightSigning-Package~31bf3856ad364e35~amd64~~10.0.15063.0.mum

So I mounted the "install.wim" of the boot media used, obtained the file in question fresh from the source, replaced it, and tried again.  It was still flagged as having a bad digital signature.  So, thinking that it may have been due to the in-place upgrade, I wiped my computer and installed from scratch.  After a few application installs (office, new adk, etc) I ran the above DISM command again only to find that I was again getting the source files could not be found error.  I then ran the pre-scan again to find that the exact same file mentioned above was still showing as having a bad digital signature.  Is this an error on the part of Windows AIO repair, or is this a Microsoft issue.  I am inclined to think it is a Microsoft issue, but wanted to get another opinion.

[Boggin]

I don't know if Shane has tested WR on 15063 yet but I'll pass this onto him.

[whiggs]

Sounds good me amigo.  Like I was saying above, I think is more of a Microsoft issue.  The application states clearly that the "mum" file in question only affects Windows updates, and the issue I am having is in regards to the DISM /online /cleanup-image /restorehealth command returning the source files could not be found, the source files which are usually obtained from Windows update.  I actually have a call scheduled with a level 2 Microsoft Tech on Monday concerning this as well, so hopefully there will be a quick fix.

[Boggin]

I've seen that quite often reported when running the /restorehealth cmd and the problems when trying to point it to the source file with the subsequent limit access cmd.

If a sfc /scannow comes up clean then it's unlikely a /restorehealth would resolve anyway.

A sfc /scannow is usually run after the /restorehealth cmd to see if any corruption remains.

I'm not sure if running dism /online /cleanup-image /startcomponentcleanup before the /restorehealth cmd would help or have any effect on the Package error, but you could give it a try.

BTW - Good luck with MS tech support and hope you get someone who knows what they are doing and don't try to fleece you out $s.

[whiggs]

Thank you for your feedback.  So SFC does not report any corruptions.  In fact, if you look at the log file I posted in the original post, it states that "The SFC (System File Checker) doesn't scan and replace some of these files, so you may need to replace them manually."  And since there is only one file, I assume that it is referring to that file.  My concern is that I have encountered this issue on two different machines in the span of less than 24 hours.  It occurred immediately after I performed an in place upgrade, so, since I assumed something must have gone wrong during the update, I ripped the iso to a usb and did a clean install.  Booted it into audit mode, did some basic installs, ran it again and boom, it was happening again.  That kind of error should not be occuring on a brand new machine build, much less an in place update where it was working fine before, you know?  While nothing may is necessarily wrong right now, I would think it would be very important to get that command to work, as it is a major repair tool that many people and applications (including Windows AIO repair) use to fix systems.

[Boggin]

I wouldn't have done a clean install as that means you will no longer be able to roll back, unless you'd created a system image while you had 14393.

Getting the error on two machines would suggest that it is a result of 15063.

I updated one machine but rolled it back.

To confirm if 15063 is the cause, I'll upgrade that machine again tomorrow and run the pre-scan on it and then get back to you.

[Boggin]

I ran a pre-scan before upgrading and that came back clean other than a Reparse Point problem for \User\Guest which the Reparse Point repair seemed to fix.

I don't know why it snagged that as I'm the only user on all of my laptops.

I upgraded as for a repair install from a bootable USB and selecting not to check for updates so that I could run the pre-scan before they had installed, but they installed at the end of the process anyway.

I got exactly the same Package file error as you which would confirm that is directly related to 1703.15063

I also got that same Reparse Point error as well.

I noticed what looked like you had also posted this query on the Bleeping.com forum.

Cross posting without informing either helper is frowned upon and on some forums is in breach of their rules because that can lead to duplication or conflict in advice.

It would seem from that that thread that you have already decided this Package error is a direct result of the upgrade, but I'd be interested in what the 2nd line MS tech has to say.

[Boggin]

I wouldn't worry about this Package error as far as future updates are concerned.

When I first ran the pre-scan after the upgrade, it was showing as 15063.0 so it mustn't have searched for updates during the upgrade as I thought it had.

I have since received the cumulative update to take that to 15063.13

[whiggs]

thanks for the verification.  BTW, I did not post this issue in bleeping.com's forums.  I don't really use that site.  What made you think I did?

[Boggin]

It was because of an almost identical worded thread I found when Googling the problem and I don't know of any other program other than WR's Pre-Scan that would snag this.

https://www.bleepingcomputer.com/forums/t/643994/windows-package-file-bad-digital-signature/

[whiggs]

Uncanny!!!  I would make that mistake as well.  Not to argue the finer details, but I fail to see, even if I were the one who posted that post, how that would be considered inconsiderate.  The likeliness of getting an issue resolved increases when the number of eyes that see it increases, until that one person who knows the answer finally replies.  So if anything, I would think that limiting the issue to just one web sites forum would do yourself a disservice, as it severely limits the number of people who can see and reply to your problem.... 

[Boggin]

I agree that posting on another forum to ask for help when there's no response on one, but otherwise cross posting is frowned upon and is a breach of forum rules on one Forum that I post on.

This is because one helper doesn't know what has already been suggested and suggestions can be duplicated.

What you have to bear in mind is that we are all volunteers that give our time freely and that time can be wasted when perhaps research is needed and both helpers come up with the same answer.

If you do post on another forum then it's best to let both helpers know so one may step back to see how the other progresses.

[whiggs]

I will be sure to keep that in mind.

[whiggs]

Hey everybody.  So I wanted to report that, since Microsoft has decided to ignore the issues prevalent in the creators update of Windows 10, I did more digging into the issue.  I then found a blog post which confirmed that the corrupt Windows package file is indeed the cause of DISM not working correctly, and it does come that way right out of the box.  However, the blog post also offers a solution: Just delete the references to the corrupt package file from the Windows registry.  There are a total of 4 registry keys: 2 are located in both
 "[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageIndex" and
 "[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages".  You will want to delete the two registry keys which contain the name of the corrupt package file: "Microsoft-Windows-TestRoot-and-FlightSigning-Package".  You will have to edit the key permissions in order to do this, as you do not have the permissions by default.  Once you delete those keys, then navigate to "C:\Windows\servicing\packages" and either move or delete the 4 files which also contain (and begin with) "Microsoft-Windows-TestRoot-and-FlightSigning-Package".  Then, run the scan again and it will continue to completion (at least as long as nothing else is wrong).  blog post can be found here:
http://borncity.com/win/2017/04/26/windows-10-v1703-fix-for-dism-error-0x800f081f/#comment-1215

[Boggin]

A dism /restorehealth worked okay on this machine yesterday, although I have had the cannot find source file error before now.

As it doesn't seem to be causing any problems for me, I'll just leave it but thanks for the info.

[whiggs]

This is only applicable if you have the creators update version of Windows 10.  Version 1703 Build 15063.250

[Boggin]

I've just learned about KB4016240 from another matter which takes it to 15063.250 and a check showed I didn't have it, even though it was released on the 25th April.

I've since downloaded it from the WU Catalog so will try a couple of dism cmds to see if they still work.