do you mean that i should look for it myself? if so, i'm not sure what i'm looking for exactly...
For a start you can use the Operation Is WriteFile filter with the Tools, Count... on Path to get an inventory of all the files which are involved. Doing that sometimes shows that there are more useful diagnostics than we were aware of otherwise.
BTW another thing that came up today in another thread is the suggestion to use WSReset.exe Have you tried that? I keep hoping that that is where they finally put in everything that is needed to help people get out of these jams. So far it seems it is
often deficient but who knows maybe something will have changed?
In fact, we can find out when it last changed... Or not...
Powershell: Get-Item wsreset.exe | fl *
| FullName : C:\windows\system32\wsreset.exe <br><br>Extension : .exe <br><br>CreationTime : 2014-11-20 01:38:59 <br><br>CreationTimeUtc : 2014-11-20 06:38:59 <br><br>LastAccessTime : 2014-11-20 01:38:59 <br><br>LastAccessTimeUtc : 2014-11-20 06:38:59 <br><br>LastWriteTime : 2014-10-28 22:34:36 <br><br>LastWriteTimeUtc : 2014-10-29 02:34:36 <br><br>Attributes : Archive |
Looks like I probably got that from the November Rollup. Do you have that? It shows as the first line of View Update History (Win-w Vi Up Hi) -- Most recent cumulative update: KB3000850
In any case, that would be another thing that you could trace with ProcMon. See if there are any interesting details written when you do that? I'm not sure if it is necessary to be elevated when you do it or not. However, one issue with that might be
that it would only reset the profile of the user is was being run under. I got that surprise once when I elevated inetcpl.cpl to do a RIES and found that I had reset my own profile (i.e. the administrator and not the one of the account I had signed in with.)
Not helpful. ; }
Good luck
Robert