On 6/1/2023 6:43 PM, T wrote:
On 6/1/23 10:06, Paul wrote:
I do not think you are actually Paul. Paul is
a mensch and a total expert at Windows. What
you just wrote is kind of ...
The people who remove malware at Bleepingcomputer,
have this process right.
They insist on running certain utilities, which dump
all sorts of details about a customer environment. They
don't remove any malware for you, "until you confess".
People who get trained as malware removers, this is
all part of the process, the "gathering info first" step.
We don't do that sort of detailed work here. The chances
of us reproducing a problem without the exact environment,
are slim to none.
*******
When MajorLanGod asked the "Strange directory and files"
question, it turned out that Heidi Eraser was the culprit.
Which the OP in that case, discovered and figured out for
himself. Since the directory name was obfuscated, I knew
right away that "Googling a random string of letters"
was going to give me zip all to work with. You know in
such a case, it is likely to be a third-party thing, and
MLG figured that out for himself.
The frequency of these problems you see, as seen in Google,
indicates the logic for refusing to hibernate a kernel
and starting from scratch, is not working right. And I've
been unable to find any evidence such logic even exists
(that an installer sets a flag to prevent Fast Start right
after a driver change).
When a Patch Tuesday comes in, the installation is pre-staged.
This leads to (apparently) some services being turned off
and turned on again, and occasionally, side effects that
hint to the user to "check the calendar for Patch Tuesday".
When you attempt to do a shutdown or a restart, the
PendMoves files are moved into place. That would be a
conservative flag, for indicating that Fast_Startup is
not advised, and a full boot is a good idea. At the time
point that PendMoves runs, more of the files are unlocked
and can be replaced with updated files.
When the system comes back up, additional moving of
files happens. And that is before the OS comes up. In some cases, the
OS does not even come up, and immediately does a restart.
The system is not "file stable", until WindowsUpdate convinces itself
that the update completed successfully. At that point, you could
conclude one more Fast_startup-free restart would be required,
before the system would be stable again.
But is this level of detail available anywhere ?
I bet Russinovich could explain it, but nobody else
seems to care.
Have you ever noticed InFlight directories in the OS ?
How long can a patch remain InFlight ? The answer seems
to be... forever. Nobody or nothing cleans that out.
The process is meant to be mysterious, and it remains... mysterious.
If you work on a Win7 disk drive that has been sitting
unused for a few years, and run Windows Update, what
do you notice ? You notice some really old updates are
scheduled to run. Whereas we were told "the latest Cumulative
is... <cough> Cumulative". Yet the updater logic does not
think so, that a Cumulative smothers all.
As for the frequency of files being updated, the people
over on WSUSOffline keep informal statistics on what files
are getting frequent updates. The kernel file is updated
frequently, a GDI file of some sort was also a player. It was
based on their knowledge of these things, that they have a
recipe over there for tipping Vista SP2 upright. Which very
few other individuals have managed to do. And this tells you,
that the Fast Startup, really should not persist past 30 days
plus however long you punch the "delay my updates" button.
It should never be able to make 90 days, ever. Needing
new kernel versions sees to that.
If certain third party driver-updaters are running on
your customer machines, these should be turned off. These
install updates that conflict with the Windows Update knowledge
of "what is the latest driver". Who knows what damage that
is doing to Fast Startup. I don't want to guess.
Paul
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)