Device Update Agent and Q815021

  • Thread starter Thread starter Peter
  • Start date Start date
P

Peter

Hi

It seems like its not possible to send out Q815021 with DUA, is that
correct?

My problem is that the file "ntdll.dll" is never moved from the DUA dir to
\windows\system32 as other files are on reboot. Maybe because ntdll.dll is
allready in use when "PendingFileRenameOperations" is executed?

My Script:
HTTPGET,0,,server,,updates/ntdll.dll,1,d:\dua\working\ntdll.dll,1
MOVEFILE,,,d:\dua\working\ntdll.dll,,d:\windows\system32\ntdll.dll,DAMOVEFIL
E_DELAY_UNTIL_REBOOT|DAMOVEFILE_REPLACE_EXISTING

PendingFileRenameOperations in regdb before reboot:
\??\d:\dua\working\ntdll.dll
!\??\d:\windows\system32\ntdll.dll

After reboot the Pending key is correct deleted but the file isn't moved :-(

Other updates like Q811493 and Q824146 works just great

Anyone have an idea?

Thanks

/peter
 
Peter,

I had a similar issue with the RPC Patch. The DLL's
were already in use, so in my script I created a oldDLL's
directory. I did a movefile command and moved the old
DLL's to the OLDDLL's directory and then moved the new
DLL's from the QFE into the System32 directory. This has
worked fine for me. Maybe that will work for you?? Here
is an example of what I am talking about:

MOVEFILE,,,C:\Windows\System32
\rpcrt4.dll,,C:\OLDDLLS\oldrpcrt4.dll,4

DELAY,,5

MOVEFILE,,,C:\Updates\DUA\824146_rpcrt4.dll,,C:\Windows\Sys
tem32\rpcrt4.dll,4

Hope this helps...

Robert
 
Robert

Thx, it seems to work, but think this is very weird and must be another bug
in DUA.

When you specify DAMOVEFILE_DELAY_UNTIL_REBOOT|DAMOVEFILE_REPLACE_EXISTING
it shouldn't be necessary to move the old file first.
Have also noted that after your example, Windows is using the file from
Olddlls after the first reboot, and doesn't use the new in system32.

C:\olddlls\ntdll.dll can't be deleted / modified after first reboot
C:\windows\system32\ntdll.dll can be deleted / modified after first reboot

After a second reboot its switched and Windows is using the correct file
from System32, but this means that after first reboot Windows is still using
the old "ntdll.dll" which is unsecure.

Another thing I noticed is, the version number on the new file in System32
isn't changed before the second reboot, but from the file size I can see
that it is the new version. (Thought fileversion info was loaded when you
access the file from explorer)

Really looking forward to that day where we get a version of DUA, which
actually works. (Have read about so many issues, which should be possible to
fix in DUA for example this one, why move the file to a new location first
when you specify replace? I don't get it. Another example of a bug /
undocumented "feature" can be seen in Mario post from 26-08-2003 - Problems
setting Key with DUA)
Thanks for your answer


Would like a MS statment if this is the way to do it? to get around the
buggy DUA.

/Peter
 
Peter,

I have had exactly the same experience as you when trying to apply Q815021
via a DUA script i.e. had to reboot
twice to get the new ntdll.dll in place and being used.

A MS comment would be very nice on this issue.

Andy
 
Peter,

I have had exactly the same experience as you when trying to apply
Q815021 via a DUA script i.e. had to reboot
twice to get the new ntdll.dll in place and being used.

A MS comment would be very nice on this issue.
Click to expand...

OK, I forwarded this on to our DUA test guys - they came up with the
following workaround.

//*********************************************
//** The following DUA script demonstrates how
//** to update system files.
//*********************************************


//************************************************
//** Rename the target, the target could be locked
//************************************************
MOVEFILE,,,d:\windows\system32\ntdll.dll,,d:\windows\system32\ntdll_old.d
ll

//****************************************************
//** Move the new version into the system32 directory
//****************************************************
MOVEFILE,,,d:\duagent\new_ntdll.dll,,d:\windows\system32\ntdll.dll

//**********
//** Reboot
//**********
REBOOT,,DAREBOOTOPT_REBOOT

//*******************************************
//** Delete the old version after rebooting
//*******************************************
DELETEFILE,,,d:\windows\system32\ntdll_old.dll


The problem isn't with DUA, but with the underlying API's we're using to
do the MOVEFILE command. This workaround is the best solution, short of
updating a few Windows system API's - a bit quicker too...
 
Back
Top