Robert,
I installed the update in safe mode - actually in safe mode with
network, because the first pass failed cuz the network was
unavailable.
The update downloaded an extra 8 megs of stuff (it already did that
before), and then installed itself in a blink. I hardly had the time
to see the names of the different kernels flashing on the screen.
Now look at the context of the AtomicReplaceFile that worked:
130.531: ProcessSetupContentSection: PROCESS_SETUP_CONTENT_OP_INSTALL:
Copied c:\1b0902739aac905064a6483a\update\branches.inf ->
c:\windows\$hf_mig$\KB840987\update\branches.inf.
130.546: MyMakePerFileExceptionA: MakePerFileException failed;
error=0x6ba.
130.671: AtomicReplaceFile: Calling HpReplaceSystemModule(
C:\WINDOWS\system32\ntoskrnl.exe, HFX6.tmp, _000005_.tmp, FALSE ).
130.671: AtomicReplaceFile: HpReplaceSystemModule succeeded.
Then compare it with the one that failed before:
131.641: ProcessSetupContentSection: PROCESS_SETUP_CONTENT_OP_INSTALL:
Copied c:\8fe4c1d9d11b67db22f37a2e3777682c\update\branche s.inf ->
c:\windows\$hf_mig$\KB840987\update\branches.inf.
131.766: AtomicReplaceFile: Calling HpReplaceSystemModule(
C:\WINDOWS\system32\ntoskrnl.exe, HFX11.tmp, _000027_.tmp, FALSE ).
See that "130.546: MyMakePerFileExceptionA" operation that didn't
existed in the failing attempts?
Two possible ways to analyze this:
- This happened because I was running in safe mode
- This happened because we just went accross a "patch Tuesday" and
something in the update has changed.
My first reaction was to consider the later, because of the
MyMakePerFileExceptionA that suddently appeared in the succesful log.
But after more careful analysis, it looks like the former is the right
one:
- I didn't reload the update since Patch Tuesday: I used the one that
was sitting on my disk from the latest attempt, that was when I posted
that help message on the newsgroup
- And in addition, comparing the failing logs with the successful one,
the size of the files that the update downloaded were the precisely
the same number of bytes.
Ergo, I owe you one :-)
Thanks a bunch! /Ph.
On Tue, 8 Feb 2005 15:29:42 -0500, "Robert Aldwinckle"
<> wrote:
>"Philippe Auphelle" <> wrote in message
>news:.. .
>> Hi,
>>
>> I have a weird problem updating a 2003 standard server: When Windows
>> Update attempts to install KB840987, the installation never completes.
>> The machine seems to hang, Taskbar date/time freezes. The mouse cursor
>> still moves, and the installation progress bar moves extreemely slowly
>> until it reaches the end, but the install never completes, whatever
>> the time I wait. Task manager is not accessable, soft power off
>> doesn't do a thing, etc.
>>
>> After hours of wait, I had to hard reset the machine.
>> On restart, ntoskrnl.exe was missing.
>> I reinstalled it from ntkrnlmp.exe on the install CD (yes, the machine
>> is a dual Xeon, Intel-brand motherboard).
>> After reboot, the same problem occurred.
>> I tried a Repair re-installation, and when I launched again the same
>> WinUpdate, the same problem occured, except that time, the kernel was
>> not lost. Ditto with fsc.
>>
>> Looking at the KB840987.log is quite interesting:
>> The log ends with:
>>
>> 132.250: AtomicReplaceFile: Calling HpReplaceSystemModule(
>> C:\WINDOWS\system32\ntoskrnl.exe, HFX1A.tmp, _000028_.tmp, FALSE ).
>>
>>
>> Looking again at the log, I found something else disturbing:
>> The patch hangs at each and every attempt at the very same place,
>> trying to do an AtomicReplaceFile, *but* it doesn't try to replace the
>> same file each time:
>> Sometimes it tries to replace ntoskrnl.exe, and sometimes it tries to
>> replace ntkrnlpa.exe:
>
>Do you have custom versions of both those modules because
>of your MP? If so, were they from the manufacturer?
>And if so, I think I would treat them the same way that many users
>treat critical updates to drivers from MS: go back to the manufacturer's
>site first to find out what is going on. Of course with such modules
>it may be more difficult to ignore critical updates.
>
>BTW almost all of the logs that I have looked at which were found
>after searching for AtomicReplaceFile have as a next line:
>
>DoNoDelayReplace: Atomic replace support not implemented; disabling.
>
>Then there would be lines which showed which files were copied
>to System directories and which files were delay copied
>(e.g. copied to System directories during a boot).
>
>What also might be interesting in your log would be what comes
>before that. E.g. any signs that services needed to be stopped.
>
>
>For something to try the only thing that comes to mind is to see
>if downloading and installing the update manually works any better.
>As refinements of that idea you could perhaps also try doing it
>with the Administrator userid during a safe boot. E.g. manual
>installs often seem to be more successful than automatic ones,
>perhaps because of the set of permissions given to the accounts
>that the automatic tasks run under; a safe boot should have less
>of a problem stopping tasks because there are less of them running;
>the real Administrator userid may even have more permissions on its
>account than yours; etc.
>
>
>Good luck
>
>Robert Aldwinckle
>---
>
>
>>
>> 120.437: AtomicReplaceFile: Calling HpReplaceSystemModule(
>> C:\WINDOWS\system32\ntkrnlpa.exe, HFX831A.tmp, _000004_.tmp, FALSE ).
>>
>> I disabled the antivirus (to no avail) and ran a full scan from Trend
>> Micro online scanning, and the machine wasn't infected either.
>> Apart from this, the machine doesn't seem to show any problem.
>>
>> Googling around real hard, I found a few people who had ran into the
>> same problem back in October 2004. None had a better solution than to
>> avoid that security patch (as well as a couple of other ones). Neither
>> very safe, nor very intellectually fulfilling. At least one of those
>> unhappy few also had a multi-CPU Xeon board.
>>
>> I'd be very grateful to anyone who could clue me out of this mess!
>>
>> TIA,
>>
>> Philippe Auphelle
>>
>