Update 979683 doesn't install correctly on WinSrv2003EESP2x64

Hi all!

The update 979683 is seemingly installed correctly on my W2K3SRVEEx64sp2.
But when I verify the 'hal.dll' component of the update is NOT updated.

The "KB979683.log" file states that "LoadFileQueues:
UpdSpGetSourceFileLocation for hal.dll failed: 0xe0000102"

I have verified that the 'hal.dll' is not updated in any normal locations
for 'hal.dll' under '%WINDIR%', it is still the old version.

I have seen from posts on other sites that the above error might occur when
MS engineering has done some kind of error in their quest for a perfect
update. If you are a Microsoft Engineer reading this, please alert the QFE
team.

Does anyone know of a workaround for this error?

Thanks!

See the "How to obtain help" section of
http://support.microsoft.com/kb/979683


LAban24 wrote:
> Hi all!
>
> The update 979683 is seemingly installed correctly on my W2K3SRVEEx64sp2.
> But when I verify the 'hal.dll' component of the update is NOT updated.
>
> The "KB979683.log" file states that "LoadFileQueues:
> UpdSpGetSourceFileLocation for hal.dll failed: 0xe0000102"
>
> I have verified that the 'hal.dll' is not updated in any normal locations
> for 'hal.dll' under '%WINDIR%', it is still the old version.
>
> I have seen from posts on other sites that the above error might occur
> when
> MS engineering has done some kind of error in their quest for a perfect
> update. If you are a Microsoft Engineer reading this, please alert the QFE
> team.
>
> Does anyone know of a workaround for this error?
>
> Thanks!

"LAban24" <> wrote in message
news:42CB6BAE-9DAD-4E6D-BD66-...
> Hi all!
>
> The update 979683 is seemingly installed correctly on my W2K3SRVEEx64sp2.
> But when I verify the 'hal.dll' component of the update is NOT updated.


Explain? There would undoubtedly have been a reboot required to do a copy
rename. Did you allow that to happen and check that it did? E.g. using
ReportingEvents.log (or Event Viewer).

FWIW I ran into a similar situation today with ieframe.dll. Supposedly I
have a hotfix installed for it but when I checked the version in
%windir%\System32 it was quite old. However, when I check to see what the
loaded version is, e.g. via msinfo32 when IE is running, the version that I
was expecting to see is reported. My conclusion is that the hotfix must
have been installed only into a SxS directory somewhere and it is being
loaded from there, but still made to appear that it is being loaded from
System32.


>
> The "KB979683.log" file states that "LoadFileQueues:
> UpdSpGetSourceFileLocation for hal.dll failed: 0xe0000102"
>
> I have verified that the 'hal.dll' is not updated in any normal locations
> for 'hal.dll' under '%WINDIR%', it is still the old version.


Unfortunately, hal.dll is not shown by msinfo32 but I think it might be
shown by ProcExp, e.g. under the System task. FWIW I just used this
Powershell pipeline to check on what is there
ls hal.dll | fl
but ProcExp showed me the same thing. I don't know if mine should be
different or if hal.dll could possibly be loaded from the SxS

PS C:\Windows> ls -Fi hal*.dll -R | fl

shows that one exists in SxS but that they are the same.


Hang on. Why are you looking at hal.dll anyway? The KB article doesn't
even mention it for our OS. Mine is W7 X64 so it wants the same list as
yours and for that there are only two modules listed: ntoskrnl.exe and
ntkrnlpa.exe

PS C:\Windows> ls -Fi ntoskrnl.exe -R | fl

shows there are a few of those but I do have the latest installed in
System32. ProcExp confirms the PS result (as far as it goes <w>).

The other one apparently updated SysWow64. I don't know where it would be
used or how to check it further.


HTH

Robert Aldwinckle
---


>
> I have seen from posts on other sites that the above error might occur
> when
> MS engineering has done some kind of error in their quest for a perfect
> update. If you are a Microsoft Engineer reading this, please alert the QFE
> team.
>
> Does anyone know of a workaround for this error?
>
> Thanks!