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

>-----Original Message-----
>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\ntdl
l.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
>
>
>
>.
>

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



"Robert" <(E-Mail Removed)> wrote in message
news:0ed201c37de4$cb1ac2d0$(E-Mail Removed)...
> 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
>
> >-----Original Message-----
> >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\ntdl
> l.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 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" <@> wrote in message
news:uuN%23%(E-Mail Removed)...
> 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

"Andy Bridge" <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

> 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.

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...

--
--Jon, MS

This posting is provided "AS IS" with no warranties, and confers no
rights.

Thanks

Nice to know that is were the right way to do it

/Peter

"Jon Fincher" <(E-Mail Removed)> wrote in message
news:Xns940D8D846EE04jonfionlinemicrosoft@157.54.3.22...
> "Andy Bridge" <(E-Mail Removed)> wrote in
> news:(E-Mail Removed):
>
> > 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.
>
> 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...
>
> --
> --Jon, MS
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.