Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories

Dr. Watson user.dmp file problems on Windows XP?

strangedubstrangedub Member Posts: 17
I was wondering if anyone else had run into problems related to the Dr. Watson user.dmp file on Windows XP? In particular has anyone seen a situation where a program aborts but is unable to overwrite the existing user.dmp file? Or has anyone seen a situation where a program running under an Administrators-group user-id is unable to copy the existing user.dmp file (receiving an I/O error 05)? We've seen both situations and it seems to occur only on Windows XP systems. After we manually delete the old user.dmp file, the program abort sucessfully creates a new user.dmp, and the program that copies the file has no problem.

Any and all help is appreciated.

Michael Rose
-Unisys Corp

Comments

  • strangedubstrangedub Member Posts: 17
    Just an update on our user.dmp file problems on WinXP:

    It now looks like (in at least 2 of the cases) user.dmp may have been propogated from one system to another by "ghosting" or other HD image copying process. We believe that the user.dmp that got created by cloning is owned by a non-existent user, and that is why it can't be overwritten or copied. So perhaps we may have a procedural problem.

    Still some questions remain: why has this just shown up on WinXP, while we never saw it on Win2K or earlier versions of Windows? (We've been creating "pre-load" images for our servers for some years now.) Also, why can someone in the Administrators group delete the file manually (via File Explorer) but not overwrite it or copy it to another location? And why can't this user view the current owner of the file, but instead must assume ownership before displaying the file owner?

    Any help, info, or relevant links appreciated.
    Michael Rose
    Unisys Corp

    : I was wondering if anyone else had run into problems related to the Dr. Watson user.dmp file on Windows XP? In particular has anyone seen a situation where a program aborts but is unable to overwrite the existing user.dmp file? Or has anyone seen a situation where a program running under an Administrators-group user-id is unable to copy the existing user.dmp file (receiving an I/O error 05)? We've seen both situations and it seems to occur only on Windows XP systems. After we manually delete the old user.dmp file, the program abort sucessfully creates a new user.dmp, and the program that copies the file has no problem.
    :
    : Any and all help is appreciated.
    :
    : Michael Rose
    : -Unisys Corp
    :

  • strangedubstrangedub Member Posts: 17
    The root cause of I/O error 05 (access denied) in attempting to copy user.dmp was a change in Windows XP concerning the default security settings of this file. The statement I got from Microsoft (after being on the phone over 4 hours with several patient support people) is this:
    "User.dmp gets permissions assigned when it gets created by user and it is not inherited from parent folder. It is by design."

    Apparently, user.dmp was moved into User Profile space in WinXP, and due to special User Profile security logic, it will not inherit security from its parent folder. Instead it gets specific ACL settings -- that does NOT include the Administrators group. Note that this only applies to user.dmp, and not drwtsn32.log.

    The most direct fix is to change the Crash Dump (user.dmp) location so that it is not within User Profile space. This can be done through Dr. Watson or directly by setting the following registry key value:
    HKLMSoftwareMicrosoftDrWatsonCrashDumpFile

    Here's the fun bit: it appears that this "special" handling of user.dmp (where it doesn't inherit ACLs) only applies to Windows XP Pro. I have verified that the embedded version of Windows XP acts normally -- although user.dmp is in the same location as in standard XP, it inherits ACLs just fine. As for Windows 2003 Server, another fun fact: the default Watson location has changed again. I found Watson files at the following location:
    C:Documents and SettingsLocal SettingsApplication DataMicrosoftDr Watson.

    It appears that user.dmp inherits ACLs from parent normally in Win2003.

    Is this stuff documented anywhere?

    -Michael Rose
    Unisys Corp.


    : Just an update on our user.dmp file problems on WinXP:
    :
    : It now looks like (in at least 2 of the cases) user.dmp may have been propogated from one system to another by "ghosting" or other HD image copying process. We believe that the user.dmp that got created by cloning is owned by a non-existent user, and that is why it can't be overwritten or copied. So perhaps we may have a procedural problem.
    :
    : Still some questions remain: why has this just shown up on WinXP, while we never saw it on Win2K or earlier versions of Windows? (We've been creating "pre-load" images for our servers for some years now.) Also, why can someone in the Administrators group delete the file manually (via File Explorer) but not overwrite it or copy it to another location? And why can't this user view the current owner of the file, but instead must assume ownership before displaying the file owner?
    :
    : Any help, info, or relevant links appreciated.
    : Michael Rose
    : Unisys Corp
    :
    : : I was wondering if anyone else had run into problems related to the Dr. Watson user.dmp file on Windows XP? In particular has anyone seen a situation where a program aborts but is unable to overwrite the existing user.dmp file? Or has anyone seen a situation where a program running under an Administrators-group user-id is unable to copy the existing user.dmp file (receiving an I/O error 05)? We've seen both situations and it seems to occur only on Windows XP systems. After we manually delete the old user.dmp file, the program abort sucessfully creates a new user.dmp, and the program that copies the file has no problem.
    : :
    : : Any and all help is appreciated.
    : :
    : : Michael Rose
    : : -Unisys Corp
    : :
    :
    :

Sign In or Register to comment.