FSUTIL and Windows Update Failures.

Please provide more information so that the cause of your problem may be diagnosed.

 

Please restart your computer and allow 20 minutes for the system to run before uploading information required to help me investigate your problem. When examining Event Viewer log files many, not all, problems show in the period immediately after the computer has been booted.

 

Please provide a copy of your System Information file. To access your System Information file select the keyboard shortcut Win+R, type msinfo32 and click OK . Place the cursor on System Summary. Select File, Export and give the file a name noting where it is located. Click Save. Files in the txt file format are preferred.Do not place the cursor within the body of the report before exporting the file.The system creates a new System Information file each time system information is accessed. You need to allow a minute or two for the file to be fully populated before exporting a copy. Please upload the file to your OneDrive, share with everyone and post a link here. If the report is in a language other than English, please state the language.

 

Please upload to your OneDrive and share with everyone a copy of your System log file from your Event Viewer and post a link here. Please remove any earlier copies of the logs from your OneDrive.

 

To access the System log select the keyboard shortcut Win+R, type eventvwr.msc and press the ENTER key. From the list in the left side of the window select Windows Logs and System. Place the cursor on System, select Action from the Menu and Save All Events as (the default evtx file type) and give the file a name. Do not provide filtered files. Do not place the cursor in the list of reports before selecting Action from the menu. Do not clear logs whilst you have a continuing problem.

 

For help with OneDrive see paragraph 9.3:

http://www.gerryscomputertips.co.uk/MicrosoftCommunity1.htm

The reason I say this is in the nature of the message telling us that Windows couldn't complete the updates, and it is rolling back. It just seems like a common sense message to give IF Windows Update Software is using the disk's journal method at the end of the process to confirm installation integrity. (This is a common practice used by us software programmers.)

The file system's journal capability isn't designed to detect problem with file integrity on a running system...  Instead it was designed to keep track of write transactions in case of a quick eject, power failure, etc. so that the file system could "roll back" a partially complete transaction.

So, if a file got corrupted due to a bad download, antivirus twiddling, etc. the Journaling system will not be of any help.  In fact, I rather doubt that the Windows Update service interacts with the Journaling system at all.

I might be wrong, but I think you're barking up the wrong tree...

It is really time to stop guessing... The Windows Update Agent (WUA) API has been around since Windows XP and is well documented.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa387099(v=vs.85).aspx

Thank you sincerely for your response. Please see the link by srfreeman  https://msdn.microsoft.com/en-us/library/windows/desktop/aa387099(v=vs.85).aspx

I have pasted an excerpt below.

"System administrators can use WUA to programmatically determine which updates should be applied to a computer, download those updates, and then install them with little or no user intervention.

Independent software vendors (ISV) and end-user developers can integrate WUA features into computer management or update management software to provide a seamless operating environment."

In my original post, my concern was two fold. 1. Is it possible that multiple processes could be started at the same time by multiple ISV's that are massive enough to trigger an update to the journal that other ISV's were relying on before it slipped off of the stack? I can also envision time out errors. For instance, surely the process would be done in 15 seconds, therefore; as a responsible ISV, I'll terminate the process in 20 seconds to avoid malware. I also have no doubt that the ISV has "tunnel vision", and only tests his one application, and not in an environment where massive multiple processes are taking place. 2. Is there some prevention mechanism that makes all of the various processes wait their turn such that the journal is stable and reliable?

Was it Einstein who said "We cannot solve our problems with the same thinking that we used when we created them."? I wouldn't hold the Update Agent nor the Journal as infallible, but I'm sure they work well. Now that Microsoft is moving towards "Windows as a Service", the possibility exists that multiple vendors are trying to use the journal all at once, and the old tunnel vision thinking of how it used to be OK when used one at a time no longer applies, or to say it another way, is beyond the capacity of an old XP component.

I was merely hoping I could "flush" the journal analogously to see if it would help similar to flushing the software distribution folder or the database that does not seem to ever work for us by the troubleshooter. (I will go one step further and bet you this either is, or it at least could be a future problem without controlling ISVs protocol somehow.) To explain, I have programmed for over 35 years, and I have been caught up in OS architecture changes where older code called a dll that was busy, and a new dll was started by the OS automatically, not having the same information as the former dll. Looking back, I can say I had the "same thinking flaw" when the OS didn't act the way I thought it always did. Our mind needs to get off disk errors, bad sectors, SSD flaws and hardware. Modern hardware is too reliable for that to be the first avenue of approach.

So, what do you say? Nothing ventured, nothing gained! Could I get some help with my questions on using FSUtil? We can always that that the Journal has now been shown not to be the problem when we are done!  

Thank sincerely for you for your reply. Great link to add to the discussion! This points directly to a flow chart where Update evaluates the "aftermath" of an update. I believe ISVs are either using the system improperly that provide drivers, software, etc., or, such things are not Windows 10 approved. To augment the discussion and amplify the questions, and bear in mind they are just questions, please read my reply to graye's post on December 29, 2016. The Update model points to 'Update Result' block in the flow diagram. I believe that each of the installations are fine, but they are not reporting to update as being completed simply from observing that installations reach 100%, but the Update mysteriously rolls back because something failed in the 'Update Result' section. (It could also explain why some users get unknown errors, or, fictitious error codes that could simply be typo's from an ISV's code.)

Jerry,

The cause of my problem is that Windows Update does not work. "There it lies." For all of us that suffer under the new venture by Microsoft that is trying to move towards "Windows as a Service", it is clear that Microsoft has no answer as to why Windows Update does not work. I wish to focus on what side the problem exists by trial and error, if not by reason. Every user had a functional computer and operating system until Windows 10 came out. There just isn't such a massive leap in hardware architecture out there to explain it. For instance, if I bought the absolute latest HP, I wouldn't get any more features than I have now. (I might get the next generation in I7, say a 7000 number as opposed to a 5000 number, but so what.)

I have submitted reports, had tech support, and have lost massive amounts of time doing clean installs THAT NEVER WORK! I'm not going to waste my time here with more boiler plate answers. As a moderator, if you want to knock me off, go ahead, however; you just might learn something if you don't. Focus on the questions of users. Ask questions as to what observations led them to their hypothesis. Investigate those hypothesis, or, let others investigate those hypothesis, don't dismiss them from other posts that are related, and this forum will be a better place to come.

Nothing I could submit would be helpful related to the questions that I asked. It is up to experienced users to get to the bottom of the trouble, and as you read the post thoroughly, if I'm wrong, or there is something you think might be helpful, ask it then. What might be helpful is to compile a list of posts that are update failure related, and then send out a survey asking for the general information you seek. That could be evaluated by "update detectives" to see if a pattern emerges. My guess is that will go no where. Why do I say that? Because before Win10 ever gets installed, the computers are checked for WHQL! In other words, it has already been done in the laboratory, or at least, it should have been done in the laboratory. Anything else is just software, and the only software in question is that provided by Microsoft.

To continue to get bombarded with DISMs, Troubleshooters, requests for hardware, etc., (and other old ways of thinking) will only demoralize users from pursuing what is going wrong, a ruin the only chance Windows has of ever getting "Windows as a Service" off of the ground. I am doing my best to be sincere here! Now, if you do decide to knock me off, is there an appeal process?

Rants achieve nothing and are a total waste of time. You will not resolve your problem by inaction and blaming Microsoft, as Windows Update works on millions of computer including three here.

By uploading the two files requested I may be able to confound you by fixing what is preventing it updating!

Your rant is replete with misinformation... the noted link does not point directly to a flow chart of any kind.

Your "The command (fsutil dirty querry c:) may not tell the whole story..." leads some one to believe there is a story to be told, which is not the case. The command - fsutil dirty query C: - simply checks to see if the volume's dirty bit is set.

In your example - fsutil USN deletejournal /n /d c: - the usage of both the /n and the /d parameter simply makes no sense.

Your "...some users get unknown errors, or, fictitious error codes..." is itself fiction.

The link given: Using the Windows Update Agent API: Windows Update Object Model. Half way down the page two points of interest. Most all complaints seen to pass the download but never the Update installation result.

The complaints of others are massive that turn out to be ISV oversight, such as UAC hiding prompts that the user never sees cause UAC is on of course, pointing to that such drivers were never really tested. This leads canceled by user errors when the user did nothing. It leads to dowloads that are there, but bad Update install results that may come from an unhealthy reliance on journals by ISPs. Millions of users may only send emails and surf the net. Fewer people do real world events. Numbers don't impress me, capacity does.

Who is besides you is ranting? It is plain just factual.

Your definition of "...points directly to..." is questionable at best...

Who is this Independent Software Vendor (ISV) you bring up and what third party software are you considering to contain the noted oversight?