Re: DeleteFileW returns incorrect error code in Vista for DLLs

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Hi Jeffrey,

I appreciate you looking into this.

MSN Messenger was just an example, we actually discovered this problem with our own software when trying to replace an in-use DLL. Our software (a file manager) offers to schedule a replacement at reboot if it gets an ERROR_SHARING_VIOLATION, and it appeared in testing that this was only failing on Vista under UAC - it works fine on XP, and it works fine on Vista in locations that do not require elevation.

The EXE/DLL distinction does appear to be a red herring, and after looking at your results it does appear that we can't rely on ERROR_SHARING_VIOLATION anyway, as you show - some EXEs always return access denied.

However I do think there is still some difference between Vista + UAC and other systems. I just tested this on an XP system, and attempting to delete an in-use DLL from the Program Files folder gives the "sharing violation" error. On a Vista machine, from a non-protected location, deleting an in-use DLL gives the "sharing violation" error. On a Vista machine, from a protected location WITHOUT elevation, it gives "access denied". And on a Vista machine, WITH elevation, it STILL gives access denied.

So ignoring the EXE/DLL distinction there would still seem to be a difference on Vista when deleting from a protected location with elevated permissions.

Cheers,
Jon


""Jeffrey Tan[MSFT]"" <jetan@xxxxxxxxxxxxxxxxxxxx> wrote in message news:$WZBLKL4HHA.360@xxxxxxxxxxxxxxxxxxxxxxxxx
Hi Jon,

Sorry for letting you wait.

I have discussed this issue with some kernel team members.

First, this issue is not Vista specific. If you try this on XP or Win2003
machine, it will get the same result.
Second, further test shows that this behavior is not a common difference
between Exe and DLL. Actually, it only occurs for MSN process. For example,
when we delete the msnmsgr.exe, we will get the following error message:

C:\WINDOWS\system32>del "C:\Program Files\MSN Messenger\msnmsgr.exe"
C:\Program Files\MSN Messenger\msnmsgr.exe
The process cannot access the file because it is being used by another
process.

However, deleting all other Exes that are running will get "Access is
denied":
D:\Debugging Tools for Windows>del windbg.exe
D:\Debugging Tools for Windows\windbg.exe
Access is denied.

D:\Debugging Tools for Windows>del "C:\Windows\System32\csrss.exe"
C:\Windows\System32\csrss.exe
Access is denied.

C:\WINDOWS\system32>del ntkrnlpa.exe
C:\WINDOWS\system32\ntkrnlpa.exe
Access is denied.

D:\Debugging Tools for Windows>del "C:\Windows\System32\Notepad.exe"
C:\Windows\System32\notepad.exe
Access is denied.

Now, let's explain the behavior.

Normally, if the Exe or DLL is only loaded by the OS loader, there will be
no user-mode handle pointing to it. Only the OS kernel is using pointer to
reference it. You may verify this by using Process Explorer:
http://www.microsoft.com/technet/sysinternals/Utilities/ProcessExplorer.mspx

In the Process Explorer, if you select a normal process and press "Ctrl+H"
to open the lower handle panel, you will find no "File" type handle
pointing to the Exe or Dll. ERROR_SHARING_VIOLATION will only return if
there are open handle pointing to it and the share mode does not grant the
requested permission. Since the normal Exe and DLL do not have open handle
pointing to it, the handle share mode check will not occur. The request
directly goes into the kernel file system and STATUS_CANNOT_DELETE is
returned because the file is used by other process. This gets translated to
ERROR_ACCESS_DENIED in Win32. This translation is documented in the link
below:
"INFO: Mapping NT Status Error Codes to Win32 Error Codes"
http://support.microsoft.com/kb/113996

So deleting a normal executable module will result in ERROR_ACCESS_DENIED
win32 error code.

Then, why msnmsgr.exe will result in ERROR_SHARING_VIOLATION? I am not sure
the MSN internal work, but I assume it will treat the msnmsgr.exe as a
normal data file to use certain resources in the file. By using Process
Explorer, if you select MSN process, you will find several open handles
pointing to the msnmsgr.exe. This proves the suspicion.

Hope this helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.



.

Quantcast