Hello everyone,
When I open a dump file, loads SOS, then execute !threads command, I found the following issues. Does anyone have any hints what is the issue? The machine I am using is Windows Server 2003 x64.
0:020> !threads
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
??? 2) the file mscordacwks.dll that matches your version of mscorwks.dll is
??? in the version directory
??? 3) or, if you are debugging a dump file, verify that the file
??? mscordacwks_.dll is on your symbol path.
??? 4) you are debugging on the same architecture as the dump file.
??? For example, an IA64 dump file must be debugged on an IA64
??? machine.
You can also run the debugger command .cordll to control the debugger’s
load of mscordacwks.dll.? .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.
If you are debugging a minidump, you need to make sure that your executable
path is pointing to mscorwks.dll as well.
--------------------
regards,
George
Sos requires mscordacwks.dll to be loaded into the debugger. The “bitness”
of mscordacwks.dll loaded into the debugger *must match* the target. If you
are debugging a 64-bit target, then you must use the 64-bit version of
windbg and must have the 64-bit version of mscordacwks.dll available. If
you are debugging a 32-bit target, then you must use the 32-bit version of
windbg and must have the 32-bit version of mscordacwks.dll available.
–
Steve Johnson
On Tue, Aug 26, 2008 at 10:01 PM, Lin George wrote:
> Hello everyone,
> When I open a dump file, loads SOS, then execute !threads command, I found
> the following issues. Does anyone have any hints what is the issue? The
> machine I am using is Windows Server 2003 x64.
> --------------------
> 0:020> !threads
> Failed to load data access DLL, 0x80004005
> Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
> 2) the file mscordacwks.dll that matches your version of
> mscorwks.dll is
> in the version directory
> 3) or, if you are debugging a dump file, verify that the file
> mscordacwks_.dll is on your symbol
> path.
> 4) you are debugging on the same architecture as the dump file.
> For example, an IA64 dump file must be debugged on an IA64
> machine.
> You can also run the debugger command .cordll to control the debugger’s
> load of mscordacwks.dll. .cordll -ve -u -l will do a verbose reload.
> If that succeeds, the SOS command should work on retry.
> If you are debugging a minidump, you need to make sure that your executable
> path is pointing to mscorwks.dll as well.
> --------------------
> regards,
> George
>
>
>
Hi Steve,
Good advice. My situation is,
- I ask the network admin to generte a dump for me, and sent me then I open it on my local computer and found this error, after loading sos, !threads is the 1st command I am executing;
- My code is managed code compiled with csc for “any CPU” configuration – not specific for x86/x64/IA64;
- I am using x64 Windbg under program files\Debugging Tools for Windows (x64) to open the dump on my 64-bit computer, so I think the Windbg should be 64-bit, correct?
- I am using the same ntsd command to generate a dump for the same application on my local computer, open it in the same method by Windbg on my local computer as well, then there is no such error.
So, there is something wrong configurition on the machine which network admin runs ntsd command? But it is also x64 machine, I am not sure how to analyze more information further? Could it be caused by different ntsd/Windbg version compatibility issues? 
regards,
George
----- Original Message ----
From: Steve Johnson
To: Kernel Debugging Interest List
Sent: Wednesday, August 27, 2008 10:07:36 AM
Subject: Re: [windbg] Failed to load data access DLL
Sos requires mscordacwks.dll to be loaded into the debugger.? The “bitness” of mscordacwks.dll loaded into the debugger must match the target.? If you are debugging a 64-bit target, then you must use the 64-bit version of windbg and must have the 64-bit version of mscordacwks.dll available.? If you are debugging a 32-bit target, then you must use the 32-bit version of windbg and must have the 32-bit version of mscordacwks.dll available.
–
Steve Johnson
On Tue, Aug 26, 2008 at 10:01 PM, Lin George wrote:
Hello everyone,
When I open a dump file, loads SOS, then execute !threads command, I found the following issues. Does anyone have any hints what is the issue? The machine I am using is Windows Server 2003 x64.
--------------------
0:020> !threads
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
??? 2) the file mscordacwks.dll that matches your version of mscorwks.dll is
??? in the version directory
??? 3) or, if you are debugging a dump file, verify that the file
??? mscordacwks_.dll is on your symbol path.
??? 4) you are debugging on the same architecture as the dump file.
??? For example, an IA64 dump file must be debugged on an IA64
??? machine.
You can also run the debugger command .cordll to control the debugger’s
load of mscordacwks.dll.? .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.
If you are debugging a minidump, you need to make sure that your executable
path is pointing to mscorwks.dll as well.
--------------------
regards,
George
— You are currently subscribed to windbg as: xxxxx@yahoo.com To unsubscribe send a blank email to xxxxx@lists.osr.com
Hi Steve,
- If I am the owner of the machine, I would like to check in Windows task manager to see whether it is 64-bit or 32-bit process by looking whether there is an appended *32 tag. Do you think it is the reliable approach?
- I think the primary suspecision is you think the target machine runs the process under 32-bit, but I am using 64-bit debugger to analyze it, correct?
If yes I have runned vertarget, here is the output, you can make conclusion whether the process which I made dump is 32-bit or 64-bit?
(Here is target machine which has performance issue’s output for remote dump on the target machine)
0:020> vertarget
Windows Server 2003 Version 3790 (Service Pack 2) MP (8 procs) Free x64
Product: Server, suite: Enterprise TerminalServer SingleUserTS
kernel32.dll version: 5.2.3790.4062 (srv03_sp2_gdr.070417-0203)
Debug session time: Wed Aug 27 09:19:48.000 2008
System Uptime: 5 days 8:11:18.359
Process Uptime: 0 days 5:00:47.000
? Kernel time: 0 days 0:00:01.000
? User time: 0 days 0:00:02.000
(Here is my local machine’s output for local dump)
0:021> vertarget
Windows Server 2003 Version 3790 (Service Pack 2) MP (2 procs) Free x64
Product: Server, suite: Enterprise TerminalServer
kernel32.dll version: 5.2.3790.4062 (srv03_sp2_gdr.070417-0203)
Debug session time: Wed Aug 27 09:13:24.000 2008
System Uptime: 6 days 21:43:44.047
Process Uptime: 0 days 0:00:06.000
? Kernel time: 0 days 0:00:00.000
? User time: 0 days 0:00:03.000
regards,
George
----- Original Message ----
From: Steve Johnson
To: Lin George
Sent: Wednesday, August 27, 2008 10:34:50 AM
Subject: Re: [windbg] Failed to load data access DLL
On Tue, Aug 26, 2008 at 10:23 PM, Lin George wrote:
?
- My code is managed code compiled with csc for “any CPU” configuration – not specific for x86/x64/IA64;
Makes no difference.? The process from which the dump was created was either a 64-bit process or a 32-bit process.?? You need to know which (hint: run ‘vertarget’ in windbg).
?
- I am using x64 Windbg under program files\Debugging Tools for Windows (x64) to open the dump on my 64-bit computer, so I think the Windbg should be 64-bit, correct?
Yep…you’re using 64-bit windbg.
?
?
So, there is something wrong configurition on the machine which network admin runs ntsd command? But it is also x64 machine, I am not sure how to analyze more information further?
Makes no difference whether it’s a 64-bit machine.? Is the process 64-bit or 32-bit?
?
Could it be caused by different ntsd/Windbg version compatibility issues?
?No, it could not.
?--
Steve Johnson
> For example, an IA64 dump file must be debugged on an IA64
machine.
Hmm, this is something new in windbg…
until recently it used to be 100% cross platform?
So now must get another x64 system to run windbg against a x64 target?
–PA
On Wed, Aug 27, 2008 at 6:46 AM, Pavel A. wrote:
> For example, an IA64 dump file must be debugged on an IA64
>> machine.
>>
>
>
> Hmm, this is something new in windbg…
> until recently it used to be 100% cross platform?
> So now must get another x64 system to run windbg against a x64 target?
>
No. The statements I’ve made about matching “bitness” apply only to the
requirements for using the SOS managed debugging extension.
–
Steve Johnson
Hi Steve,
1.
I followed your advice to run r command after load the dump file, is that operation what you expected?
2.
The output of my local computer is (which works fine with !threads command)
rax=000007ffffeee000 rbx=0000000000000001 rcx=000007fffffd8000
rdx=0000000000000000 rsi=0000000000000004 rdi=0000000000000005
rip=0000000077ef2aa0 rsp=000000001a28ffa8 rbp=0000000000000000
?r8=0000000000000008? r9=f0e0d0c0a0908070 r10=000000000000000a
r11=000000000000000b r12=000000000000000c r13=000000000000000d
r14=000000000000000e r15=000000000000000f
iopl=0??? nv up ei pl nz na pe nc
cs=0033? ss=002b? ds=002b? es=002b? fs=0053? gs=002b??? efl=00000200
The output of the school lab computer is (which reports the error message of Failed to load data access DLL when using !threads command)
0:020> r
rax=000007ffffef6000 rbx=0000000000000001 rcx=000007fffffd6000
rdx=0000000000000000 rsi=0000000000000004 rdi=0000000000000005
rip=0000000077ef2aa0 rsp=000000001974ffa8 rbp=0000000000000000
?r8=0000000000000008? r9=f0e0d0c0a0908070 r10=000000000000000a
r11=000000000000000b r12=000000000000000c r13=000000000000000d
r14=000000000000000e r15=000000000000000f
iopl=0??? nv up ei pl nz na pe nc
cs=0033? ss=002b? ds=002b? es=002b? fs=0053? gs=002b??? efl=00000200
Any conclusions?
regards,
George
----- Original Message ----
From: Steve Johnson
To: Lin George
Sent: Wednesday, August 27, 2008 6:07:23 PM
Subject: Re: [windbg] Failed to load data access DLL
On Tue, Aug 26, 2008 at 11:43 PM, Lin George wrote:
1. If I am the owner of the machine, I would like to check in Windows task manager to see whether it is 64-bit or 32-bit process by looking whether there is an appended *32 tag. Do you think it is the reliable approach?
That’ll work
?
?
2. I think the primary suspecision is you think the target machine runs the process under 32-bit, but I am using 64-bit debugger to analyze it, correct?
That’s a possibility, yes.
?
?
If yes I have runned vertarget, here is the output, you can make conclusion whether the process which I made dump is 32-bit or 64-bit?
?
Hmmm…I was mistaken.? What is the output of the r command?? See whether you have 32- or 64-bit registers.
–
Steve Johnson
Hi Pavel,
If I understand correctly, the remote machine which I create dump using ntsd and the local machine which I use Windbg to open dump are both Windows Server 2003 x64. When executing !threads command on the dump from my local machine. here is the error message, do you have any ideas?
0:020> !threads
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
??? 2) the file mscordacwks.dll that matches your version of mscorwks.dll is
??? in the version directory
??? 3) or, if you are debugging a dump file, verify that the file
??? mscordacwks_.dll is on your symbol path.
??? 4) you are debugging on the same architecture as the dump file.
??? For example, an IA64 dump file must be debugged on an IA64
??? machine.
You can also run the debugger command .cordll to control the debugger’s
load of mscordacwks.dll.? .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.
If you are debugging a minidump, you need to make sure that your executable
path is pointing to mscorwks.dll as well.
--------------------
regards,
George
----- Original Message ----
From: Pavel A.
To: Kernel Debugging Interest List
Sent: Wednesday, August 27, 2008 6:46:14 PM
Subject: Re:[windbg] Failed to load data access DLL
>? ? ? For example, an IA64 dump file must be debugged on an IA64
>? ? ? machine.
Hmm, this is something new in windbg…
until recently it used to be 100% cross platform?
So now must get another x64 system to run windbg against a x64 target?
–PA
—
You are currently subscribed to windbg as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
I want to provide more information if it could give any further ideas, the code is managed code developed by VS 2008 using C#, and run as a Windows Services. I heard that Windows Services will always use the lastest version CLR, on the remote machine, the lastest version is CLR 3.5. But I am using CLR 2.0 to make the build for the binary of the Windows Services. Could it be the cause – I mean CLR version issue?
regards,
George
----- Original Message ----
From: Steve Johnson
To: Kernel Debugging Interest List
Sent: Wednesday, August 27, 2008 7:28:25 PM
Subject: Re: [windbg] Failed to load data access DLL
On Wed, Aug 27, 2008 at 6:46 AM, Pavel A. wrote:
? ? For example, an IA64 dump file must be debugged on an IA64
? ? machine.
Hmm, this is something new in windbg…
until recently it used to be 100% cross platform?
So now must get another x64 system to run windbg against a x64 target?
No.? The statements I’ve made about matching “bitness” apply only to the requirements for using the SOS managed debugging extension.
–
Steve Johnson
— You are currently subscribed to windbg as: xxxxx@yahoo.com To unsubscribe send a blank email to xxxxx@lists.osr.com
Thanks Steve!
1.
Does the following file exist on your debugger machine?:? C:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscordacwks.dll.
Yes. I checked manually on my local debugging computer.
2.
Also, I’m assuming that the dump was taken from a process running CLR version 2+.? Is that correct?? (lmvm mscorwks)
I am not sure. Here is some background information I just sent in another email, any comments or ideas?
I want to provide more information if it could give any further ideas, the code is managed code developed by VS 2008 using C#, and run as a Windows Services. I heard that Windows Services will always use the lastest version CLR, on the remote machine, the lastest version is CLR 3.5. But I am using CLR 2.0 to make the build for the binary of the Windows Services. Could it be the cause – I mean CLR version issue?
(lmvm mscorwks)
On my local computer, I have runned the command lmvm (from my local debugging machine) when loading the crash dump generated from the remote machine. Here is the output. Any ideas?
0:020> lmvm mscorwks
start??? end??? module name
000006427f330000 000006427fd21000?? mscorwks?? (deferred)???
??? Image path: C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\mscorwks.dll
??? Image name: mscorwks.dll
??? Timestamp:??? Fri Apr 13 12:21:34 2007 (461F054E)
??? CheckSum:??? 009E4F75
??? ImageSize:??? 009F1000
??? File version:??? 2.0.50727.832
??? Product version:? 2.0.50727.832
??? File flags:??? 0 (Mask 3F)
??? File OS:??? 4 Unknown Win32
??? File type:??? 2.0 Dll
??? File date:??? 00000000.00000000
??? Translations:??? 0409.04b0
??? CompanyName:??? Microsoft Corporation
??? ProductName:??? Microsoft?.NET Framework
??? InternalName:??? mscorwks.dll
??? OriginalFilename: mscorwks.dll
??? ProductVersion:?? 2.0.50727.832
??? FileVersion:??? 2.0.50727.832 (QFE.050727-8300)
??? FileDescription:? Microsoft .NET Runtime Common Language Runtime - WorkStation
??? LegalCopyright:?? ?Microsoft Corporation.? All rights reserved.
regards,
George
----- Original Message ----
From: Steve Johnson
To: Lin George
Sent: Wednesday, August 27, 2008 7:51:43 PM
Subject: Re: [windbg] Failed to load data access DLL
On Wed, Aug 27, 2008 at 7:36 AM, Lin George wrote:
Hi Steve,
1.
I followed your advice to run r command after load the dump file, is that operation what you expected?
2.
The output of my local computer is (which works fine with !threads command)
?..
OK, so your debugger and target match, so that’s not the problem.
Does the following file exist on your debugger machine?:? C:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscordacwks.dll.
Also, I’m assuming that the dump was taken from a process running CLR version 2+.? Is that correct?? (lmvm mscorwks)
–
Steve Johnson
Certainly not for native code. Steve Johnson was mentioning something about requiring to match the local debugger platform with the platform that the .NET was running as when the dump file was made.
(Which would be a fairly ironic thing, given the supposedly “cross-platform” nature of .NET. Hooray for managed code.)
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Wednesday, August 27, 2008 6:46 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Failed to load data access DLL
For example, an IA64 dump file must be debugged on an IA64
machine.
Hmm, this is something new in windbg…
until recently it used to be 100% cross platform?
So now must get another x64 system to run windbg against a x64 target?
–PA
You are currently subscribed to windbg as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Thanks Skywing,
So you think the root cause is the remote machins which is used to generate the dump, and the local machine, which is used to debug the dump are different "platform"s? They are both Windows Server 2003 x64, what do you mean the “platfom” in my context?
regards,
George
----- Original Message ----
From: Skywing
To: Kernel Debugging Interest List
Sent: Wednesday, August 27, 2008 10:08:33 PM
Subject: RE: Re:[windbg] Failed to load data access DLL
Certainly not for native code.? Steve Johnson was mentioning something about requiring to match the local debugger platform with the platform that the .NET was running as when the dump file was made.
(Which would be a fairly ironic thing, given the supposedly “cross-platform” nature of .NET.? Hooray for managed code.)
- S
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Wednesday, August 27, 2008 6:46 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Failed to load data access DLL
>? ? ? For example, an IA64 dump file must be debugged on an IA64
>? ? ? machine.
Hmm, this is something new in windbg…
until recently it used to be 100% cross platform?
So now must get another x64 system to run windbg against a x64 target?
–PA
—
You are currently subscribed to windbg as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com