tracking down error in MFC42.dll

[Eric Margheim]

I have a bug in my ATL component code that is generating an Application
Error and COM+ error in the Event Viewer. I'm trying to pin down the source
code generating the error. The Application Error tells me it's in
MFC42.DLL and gives me a fault address. Can I use this to find out what
MFC call is blowing up?

I also have the call stack information in the COM+ error. I'm having
trouble making sense of it too.

Any thoughts on best course to track this down? I've put a bunch of
try/catch blocks in existing code in hopes to trap the next time it occurs.
It should send me an email if it catches anything but I'm not 100% confident
it will.

[Ajay Kalra]

It appears to be in release build only. Can you not reproduce it in
debug build. It will belp as you will have the stack to look at.

---
Ajay

Post by Eric Margheim
I have a bug in my ATL component code that is generating an Application
Error and COM+ error in the Event Viewer. I'm trying to pin down the source
code generating the error. The Application Error tells me it's in
MFC42.DLL and gives me a fault address. Can I use this to find out what
MFC call is blowing up?
I also have the call stack information in the COM+ error. I'm having
trouble making sense of it too.
Any thoughts on best course to track this down? I've put a bunch of
try/catch blocks in existing code in hopes to trap the next time it occurs.
It should send me an email if it catches anything but I'm not 100% confident
it will.

[Eric Margheim]

Post by Ajay Kalra
It appears to be in release build only. Can you not reproduce it in
debug build. It will belp as you will have the stack to look at.

Ajay,

I haven't been able to reproduce locally even with Release build. I'm not
sure that it wouldn't happen in Debug. I'll try putting a debug build in
our test lab in hopes of catching it. So you're saying the debug build
would give me more info? Will the Call Stack be more informative? There
is a call stack when the COM+ errors occur but it just shows the modules
involved.

Currently I put a new version out that has proper try/catch blocks around
all the methods available to the caller and if an exception is caught it
should email me with the line # and file name. I didn't get any emails
Friday afternoon. I'm hoping it catches something on Monday. I was able
to throw an exception in a test DLL with some hacked code and it did hang
the COM+ Application a couple times just like it's doing in production.

Thanks

Eric

Post by Ajay Kalra
Ajay

Post by Eric Margheim
I have a bug in my ATL component code that is generating an Application
Error and COM+ error in the Event Viewer. I'm trying to pin down the source
code generating the error. The Application Error tells me it's in
MFC42.DLL and gives me a fault address. Can I use this to find out what
MFC call is blowing up?
I also have the call stack information in the COM+ error. I'm having
trouble making sense of it too.
Any thoughts on best course to track this down? I've put a bunch of
try/catch blocks in existing code in hopes to trap the next time it occurs.
It should send me an email if it catches anything but I'm not 100% confident
it will.

[Ajay Kalra]

Post by Eric Margheim

Post by Ajay Kalra
It appears to be in release build only. Can you not reproduce it in
debug build. It will belp as you will have the stack to look at.

Ajay,
I haven't been able to reproduce locally even with Release build. I'm not
sure that it wouldn't happen in Debug. I'll try putting a debug build in
our test lab in hopes of catching it. So you're saying the debug build
would give me more info? Will the Call Stack be more informative?

Certainly. Call stack will point to where the failure occured and show
you the stack. Its a very good place to start. You will need to pass on
the pdb files on to test machine as well.

Another way to deal with this in Release build is to log all the entry
points of your app in a log file. When failure occurs, you can always
look at the log and it will give you some clue as to where to look in
your source.

---
Ajay

[Oleg Starodumov]

Post by Eric Margheim
Currently I put a new version out that has proper try/catch blocks around
all the methods available to the caller and if an exception is caught it
should email me with the line # and file name.

Consider using __try..__except and minidump instead of try..catch -
it should give you the call stack at the moment of the exception,
plus lots of other useful information (depending on what you put into
the minidump), plus it does not need symbols on the remote system.

You can use something like shown here:
http://www.debuginfo.com/examples/src/debugfilters/FilterExcept.cpp

Here is how to debug a minidump:
http://www.codeproject.com/debug/postmortemdebug_standalone1.asp
http://www.debuginfo.com/articles/easywindbg2.html#crashdumpanalysis
(lots of additional information can be found on the net)

Also it could be possible to determine the name of the function in mfc42.dll
where the exception occurred, if you know the version number of the dll
installed on that system. (Without call stack it might or might not be useful,
so having a minidump is better anyway)

Regards,
Oleg
[VC++ MVP http://www.debuginfo.com/]

[Eric Margheim]

Post by Oleg Starodumov

Post by Eric Margheim
Currently I put a new version out that has proper try/catch blocks around
all the methods available to the caller and if an exception is caught it
should email me with the line # and file name.

Consider using __try..__except and minidump instead of try..catch -
it should give you the call stack at the moment of the exception,
plus lots of other useful information (depending on what you put into
the minidump), plus it does not need symbols on the remote system.
http://www.debuginfo.com/examples/src/debugfilters/FilterExcept.cpp
http://www.codeproject.com/debug/postmortemdebug_standalone1.asp
http://www.debuginfo.com/articles/easywindbg2.html#crashdumpanalysis
(lots of additional information can be found on the net)
Also it could be possible to determine the name of the function in mfc42.dll
where the exception occurred, if you know the version number of the dll
installed on that system. (Without call stack it might or might not be useful,
so having a minidump is better anyway)
Regards,
Oleg
[VC++ MVP http://www.debuginfo.com/]

Oleg, thanks for the great info. I'll read through the links you've
posted. Unfortunately my try/catch blocks are not catching the exception.
I would think that if an exception happened in MFC42.dll that it would be
thrown up to the calling function but that may not be the case. I know
the version of MFC42.DLL and have the address the Application Error is
saying. Also the call stack shows offsets.

I've pasted in the errors below. What tools can I use to drill into the
source of the error?

Thanks

Eric

Application Error Category (100) EventID 1000
Faulting application dllhost.exe, version 5.2.3790.0, faulting module
mfc42.dll, version 6.6.8063.0, fault address 0x00026e12.



COM+ Error EventID 4786
The system has called a custom component and that component has failed and
generated an exception. This indicates a problem with the custom component.
Notify the developer of this component that a failure has occurred and
provide them with the information below.
Component Prog ID:
Server Application ID: {0E90D36F-88CC-4C6D-9456-3B414695A12B}
Server Application Instance ID:
{CFD48FF6-AED9-407B-BF45-32FF3229B8BF}
Server Application Name: Prism Reports
The serious nature of this error has caused the process to terminate.
Exception: C0000005
Address: 0x73ED6E12
Call Stack:
MFC42!Ordinal6585 + 0x82
MFC42!Ordinal1585 + 0x3f
MFC42!Ordinal2027 + 0x1a
MFC42!Ordinal926 + 0x56
PRISMRptCom!DllUnregisterServer + 0x32fd4
PRISMRptCom!DllUnregisterServer + 0x2c299
PRISMRptCom!DllUnregisterServer + 0x641e
RPCRT4!NdrServerInitialize + 0x462
RPCRT4!NdrStubCall2 + 0x217
RPCRT4!CStdStubBuffer_Invoke + 0x82
OLEAUT32!VariantTimeToDosDateTime + 0x1827
ole32!WdtpInterfacePointer_UserMarshal + 0x13fa
ole32!WdtpInterfacePointer_UserMarshal + 0x13ad
ole32!ProgIDFromCLSID + 0x1fd3
ole32!ProgIDFromCLSID + 0x1dd1
ole32!WdtpInterfacePointer_UserMarshal + 0x1e5f
ole32!WdtpInterfacePointer_UserMarshal + 0x116c
ole32!WdtpInterfacePointer_UserMarshal + 0x1e6f
RPCRT4!I_RpcGetBuffer + 0x1d8
RPCRT4!I_RpcGetBuffer + 0x159
RPCRT4!I_RpcGetBuffer + 0x7f
RPCRT4!NdrConformantArrayMemorySize + 0x558
RPCRT4!MesEncodeIncrementalHandleCreate + 0xadc
RPCRT4!NdrSimpleStructMemorySize + 0x12ac
RPCRT4!NdrSimpleStructMemorySize + 0x138c
RPCRT4!NdrSimpleStructMemorySize + 0x1224
RPCRT4!NdrSimpleStructMemorySize + 0xbec
RPCRT4!NdrSimpleStructMemorySize + 0xc2d
RPCRT4!NdrSimpleStructMemorySize + 0x8de
RPCRT4!I_RpcTransGetThreadEvent + 0x39c
RPCRT4!I_RpcTransGetThreadEvent + 0x188
RPCRT4!I_RpcLogEvent + 0xe92
kernel32!GetModuleFileNameA + 0xeb

[Oleg Starodumov]

Post by Eric Margheim
Unfortunately my try/catch blocks are not catching the exception.
I would think that if an exception happened in MFC42.dll that it would be
thrown up to the calling function but that may not be the case.

try..catch is not useful when catching non-C++ exceptions (like access violation
exception in this case). You will get much better results with __try..__except
and minidump (also make sure that /EHa compiler option is used in that case).

Post by Eric Margheim
Application Error Category (100) EventID 1000
Faulting application dllhost.exe, version 5.2.3790.0, faulting module
mfc42.dll, version 6.6.8063.0, fault address 0x00026e12.
...
Exception: C0000005
Address: 0x73ED6E12
MFC42!Ordinal6585 + 0x82
MFC42!Ordinal1585 + 0x3f
MFC42!Ordinal2027 + 0x1a
MFC42!Ordinal926 + 0x56
PRISMRptCom!DllUnregisterServer + 0x32fd4
PRISMRptCom!DllUnregisterServer + 0x2c299
PRISMRptCom!DllUnregisterServer + 0x641e

The beginning of the call stack resolves to the following:

mfc42!CFixedAlloc::Alloc + 0x82
mfc42!CString::AllocBuffer + 0x3f
mfc42!CString::ConcatCopy + 0x1a
mfc42!operator+ +0x56

This part of the call stack is correct, so if necessary, it should be possible to recover
the name of the first function that belongs to your component (it will be possible if your
component was built with debug information).

Inside CFixedAlloc::Alloc, it looks like one of static _afxAlloc** objects is corrupted -
its m_pNodeFree member probably contains garbage. I don't know for sure what could
be the reason of that (writing past the "boundaries" of an empty CString object, and
"reuse after delete" are the first things that come to mind).

Possible next steps with analysis of this problem could be:

- Check CString usage to ensure that there is no overwrites, and that CString objects
are not used after they have been deleted.

- Use the approach described above to collect minidumps at the moment of the exception.
The minidump should either contain full memory contents (it will make it very big, so
it's not an option if you have to transfer it over slow network) or at least data sections
of dlls (MiniDumpWithDataSegs flag should be passed to MiniDumpWriteDump).
With minidump, it will be possible to explore the state of the involved objects in detail,
and come up with a better guess of what could be the reason.

- Test your application under PageHeap. Even though it doesn't look like heap corruption
could be the direct reason of the crash, it cannot be ruled out completely.
Here is how to enable it:
http://www.debuginfo.com/tips/userbpntdll.html
Since your component is a COM+ dll, proxy/stubs can interfere with PageHeap.
So you can either unit-test your dll under PageHeap with a client that loads the DLL in-process,
and/or set the Registry setting described in the following KB article (allow exceptions to propagate):
http://support.microsoft.com/default.aspx?scid=kb;en-us;198623

- See if the problem is reliably reproducible, and see if the exception always occurs
in the same place. If so, it will be possible to use some additional debugging approaches.

Oleg
http://www.debuginfo.com/

[Eric Margheim]

Post by Oleg Starodumov

Post by Eric Margheim
Unfortunately my try/catch blocks are not catching the exception.
I would think that if an exception happened in MFC42.dll that it would be
thrown up to the calling function but that may not be the case.

try..catch is not useful when catching non-C++ exceptions (like access violation
exception in this case). You will get much better results with
__try..__except
and minidump (also make sure that /EHa compiler option is used in that case).

Post by Eric Margheim
Application Error Category (100) EventID 1000
Faulting application dllhost.exe, version 5.2.3790.0, faulting module
mfc42.dll, version 6.6.8063.0, fault address 0x00026e12.
...
Exception: C0000005
Address: 0x73ED6E12
MFC42!Ordinal6585 + 0x82
MFC42!Ordinal1585 + 0x3f
MFC42!Ordinal2027 + 0x1a
MFC42!Ordinal926 + 0x56
PRISMRptCom!DllUnregisterServer + 0x32fd4
PRISMRptCom!DllUnregisterServer + 0x2c299
PRISMRptCom!DllUnregisterServer + 0x641e

mfc42!CFixedAlloc::Alloc + 0x82
mfc42!CString::AllocBuffer + 0x3f
mfc42!CString::ConcatCopy + 0x1a
mfc42!operator+ +0x56
This part of the call stack is correct, so if necessary, it should be possible to recover
the name of the first function that belongs to your component (it will be possible if your
component was built with debug information).
Inside CFixedAlloc::Alloc, it looks like one of static _afxAlloc** objects is corrupted -
its m_pNodeFree member probably contains garbage. I don't know for sure what could
be the reason of that (writing past the "boundaries" of an empty CString object, and
"reuse after delete" are the first things that come to mind).
- Check CString usage to ensure that there is no overwrites, and that CString objects
are not used after they have been deleted.
- Use the approach described above to collect minidumps at the moment of the exception.
The minidump should either contain full memory contents (it will make it very big, so
it's not an option if you have to transfer it over slow network) or at least data sections
of dlls (MiniDumpWithDataSegs flag should be passed to
MiniDumpWriteDump).
With minidump, it will be possible to explore the state of the involved objects in detail,
and come up with a better guess of what could be the reason.
- Test your application under PageHeap. Even though it doesn't look like heap corruption
could be the direct reason of the crash, it cannot be ruled out completely.
http://www.debuginfo.com/tips/userbpntdll.html
Since your component is a COM+ dll, proxy/stubs can interfere with PageHeap.
So you can either unit-test your dll under PageHeap with a client that
loads the DLL in-process,
and/or set the Registry setting described in the following KB article
http://support.microsoft.com/default.aspx?scid=kb;en-us;198623
- See if the problem is reliably reproducible, and see if the exception always occurs
in the same place. If so, it will be possible to use some additional debugging approaches.
Oleg
http://www.debuginfo.com/

Thanks for the tips Oleg. I am conducting a test shortly to try to
reproduce the problem in our lab. If I can do this I have a nice platform
to work on as opposed to trying to do this in production.

[Eric Margheim]

Post by Oleg Starodumov

Post by Eric Margheim
Unfortunately my try/catch blocks are not catching the exception.
I would think that if an exception happened in MFC42.dll that it would be
thrown up to the calling function but that may not be the case.

try..catch is not useful when catching non-C++ exceptions (like access violation
exception in this case). You will get much better results with
__try..__except
and minidump (also make sure that /EHa compiler option is used in that case).

Post by Eric Margheim
Application Error Category (100) EventID 1000
Faulting application dllhost.exe, version 5.2.3790.0, faulting module
mfc42.dll, version 6.6.8063.0, fault address 0x00026e12.
...
Exception: C0000005
Address: 0x73ED6E12
MFC42!Ordinal6585 + 0x82
MFC42!Ordinal1585 + 0x3f
MFC42!Ordinal2027 + 0x1a
MFC42!Ordinal926 + 0x56
PRISMRptCom!DllUnregisterServer + 0x32fd4
PRISMRptCom!DllUnregisterServer + 0x2c299
PRISMRptCom!DllUnregisterServer + 0x641e

mfc42!CFixedAlloc::Alloc + 0x82
mfc42!CString::AllocBuffer + 0x3f
mfc42!CString::ConcatCopy + 0x1a
mfc42!operator+ +0x56

How did you resolve this?

Post by Oleg Starodumov
This part of the call stack is correct, so if necessary, it should be possible to recover
the name of the first function that belongs to your component (it will be possible if your
component was built with debug information).

This was with a release version that did not have debug info. I'm
attempting to duplicate with a debug version. If I can what tools do I
need to determine what function was the last function called within my code?

Post by Oleg Starodumov
Inside CFixedAlloc::Alloc, it looks like one of static _afxAlloc** objects is corrupted -
its m_pNodeFree member probably contains garbage. I don't know for sure what could
be the reason of that (writing past the "boundaries" of an empty CString object, and
"reuse after delete" are the first things that come to mind).
- Check CString usage to ensure that there is no overwrites, and that CString objects
are not used after they have been deleted.
- Use the approach described above to collect minidumps at the moment of the exception.
The minidump should either contain full memory contents (it will make it very big, so
it's not an option if you have to transfer it over slow network) or at least data sections
of dlls (MiniDumpWithDataSegs flag should be passed to
MiniDumpWriteDump).
With minidump, it will be possible to explore the state of the involved objects in detail,
and come up with a better guess of what could be the reason.
- Test your application under PageHeap. Even though it doesn't look like heap corruption
could be the direct reason of the crash, it cannot be ruled out completely.
http://www.debuginfo.com/tips/userbpntdll.html
Since your component is a COM+ dll, proxy/stubs can interfere with PageHeap.
So you can either unit-test your dll under PageHeap with a client that
loads the DLL in-process,
and/or set the Registry setting described in the following KB article
http://support.microsoft.com/default.aspx?scid=kb;en-us;198623
- See if the problem is reliably reproducible, and see if the exception always occurs
in the same place. If so, it will be possible to use some additional debugging approaches.
Oleg
http://www.debuginfo.com/

[Oleg Starodumov]

Post by Eric Margheim

Post by Oleg Starodumov

Post by Eric Margheim
MFC42!Ordinal6585 + 0x82
MFC42!Ordinal1585 + 0x3f
MFC42!Ordinal2027 + 0x1a
MFC42!Ordinal926 + 0x56
PRISMRptCom!DllUnregisterServer + 0x32fd4
PRISMRptCom!DllUnregisterServer + 0x2c299
PRISMRptCom!DllUnregisterServer + 0x641e

mfc42!CFixedAlloc::Alloc + 0x82
mfc42!CString::AllocBuffer + 0x3f
mfc42!CString::ConcatCopy + 0x1a
mfc42!operator+ +0x56

How did you resolve this?

1. Found the same version of mfc42.dll (it comes with Win2003 SP1).

2. Determined the addresses of the exported functions mentioned on the
call stack (Ordinal*). (I used WinDbg to do that, but the same can be done
with Dumpbin, Depends, etc.)

3. Run an application that uses mfc42.dll under debugger, downloaded symbols
for mfc42.dll from the MS symbol server, and used the debugger to determine
what function names correspond to the given addresses ('ln' command in WinDbg
is very convenient for that (and VS2005 has a similar command), in older VC
debuggers simply select the given address in Disassembly window and see
what function it belongs to).

The same could be done for your dll if it would be built with debug information
(so in general it is recommended to generate debug information for release builds too)

Post by Eric Margheim

Post by Oleg Starodumov
This part of the call stack is correct, so if necessary, it should be
possible to recover the name of the first function that belongs to your component
(it will be possible if your component was built with debug information).

This was with a release version that did not have debug info. I'm
attempting to duplicate with a debug version. If I can what tools do I
need to determine what function was the last function called within my code?

If you put symbols (.pdb) of your dll on the target system (in the same directory with the dll),
you will probably get the correct call stacks automatically. If symbols were not available
by some reason, use the same approach as above - determine the location of
DllUnregisterServer in your dll, and use it (and debugger on your local machine)
to calculate the function addresses and find the function names.

Oleg
http://www.debuginfo.com/

[Eric Margheim]

Post by Oleg Starodumov

Post by Eric Margheim

Post by Oleg Starodumov
mfc42!CString::ConcatCopy + 0x1a
mfc42!operator+ +0x56

How did you resolve this?

1. Found the same version of mfc42.dll (it comes with Win2003 SP1).
2. Determined the addresses of the exported functions mentioned on the
call stack (Ordinal*). (I used WinDbg to do that, but the same can be done
with Dumpbin, Depends, etc.)
3. Run an application that uses mfc42.dll under debugger, downloaded symbols
for mfc42.dll from the MS symbol server, and used the debugger to determine
what function names correspond to the given addresses ('ln' command in WinDbg
is very convenient for that (and VS2005 has a similar command), in older VC
debuggers simply select the given address in Disassembly window and see
what function it belongs to).
The same could be done for your dll if it would be built with debug information
(so in general it is recommended to generate debug information for release builds too)

Post by Eric Margheim

Post by Oleg Starodumov
This part of the call stack is correct, so if necessary, it should be
possible to recover the name of the first function that belongs to your component
(it will be possible if your component was built with debug
information).

This was with a release version that did not have debug info. I'm
attempting to duplicate with a debug version. If I can what tools do I
need to determine what function was the last function called within my code?

If you put symbols (.pdb) of your dll on the target system (in the same
directory with the dll),
you will probably get the correct call stacks automatically. If symbols were not available
by some reason, use the same approach as above - determine the location of
DllUnregisterServer in your dll, and use it (and debugger on your local machine)
to calculate the function addresses and find the function names.

I put the .pdg file on the production server along with a debug build of the
DLL with debug information turned on. I'll see if I get an error today
what the call stack shows.

In the interim I'd like to try to use WinDbg to look into my DLL and use the
call stack info from yesterdays error, which was for a Release DLL with
debug symbols turned on.

I'm a real WinDbg neophyte so bare with me. Since dllhost.exe is the
actual process attaching to it is not going to get me where I need to go, is
this correct? Do I have to change my application to load my DLL inprocess
in order to dig into it to find out what code the call stack is referring
to?

Thanks for all your help.

[Oleg Starodumov]

Post by Eric Margheim
In the interim I'd like to try to use WinDbg to look into my DLL and use the
call stack info from yesterdays error, which was for a Release DLL with debug symbols turned on.
I'm a real WinDbg neophyte so bare with me. Since dllhost.exe is the actual process attaching to it is not going to
get me where I need to go, is this correct? Do I have to change my application to load my DLL inprocess in order to
dig into it to find out what code the call stack is referring to?

You should attach the debugger to any process the DLL is loaded into
(it can be dllhost, or any other application that e.g. calls LoadLibrary on the DLL).

In WinDbg, you can do the following to determine the address of a function

Post by Eric Margheim
x yourdll!DllUnregisterServer
ln <address_of_DllUnregisterServer>+0xXXX

In VC debugger you can simply go to the given address (<address_of_DllUnregisterServer>+0xXXX)
in Disassembly window, then do R-click + Go To Source to see the source line.

Note that if your DLL was built with optimizations enabled, and its .pdb file was _not_
available on the target system, you can only trust the first function that belongs to your DLL
(addresses of other functions reported on the call stack can be incorrect and misleading
(not necessarily, but possible), since debug information was not available to the stack walker
at the moment when the call stack was taken. (If .pdb is available together with the DLL,
all functions should be correct).

Oleg

[Eric Margheim]

Post by Oleg Starodumov

Post by Eric Margheim
In the interim I'd like to try to use WinDbg to look into my DLL and use the
call stack info from yesterdays error, which was for a Release DLL with
debug symbols turned on.
I'm a real WinDbg neophyte so bare with me. Since dllhost.exe is the
actual process attaching to it is not going to
get me where I need to go, is this correct? Do I have to change my
application to load my DLL inprocess in order to
dig into it to find out what code the call stack is referring to?

You should attach the debugger to any process the DLL is loaded into
(it can be dllhost, or any other application that e.g. calls LoadLibrary on the DLL).
In WinDbg, you can do the following to determine the address of a function

Post by Eric Margheim
x yourdll!DllUnregisterServer
ln <address_of_DllUnregisterServer>+0xXXX

Ok. I've attached to the process but don't see where to put these commands
in. I tried in the command window but that's not working. Sorry for the
ignorance.

Post by Oleg Starodumov
In VC debugger you can simply go to the given address
(<address_of_DllUnregisterServer>+0xXXX)
in Disassembly window, then do R-click + Go To Source to see the source line.
Note that if your DLL was built with optimizations enabled, and its .pdb file was _not_
available on the target system, you can only trust the first function that
belongs to your DLL
(addresses of other functions reported on the call stack can be incorrect and misleading
(not necessarily, but possible), since debug information was not available
to the stack walker
at the moment when the call stack was taken. (If .pdb is available together with the DLL,
all functions should be correct).
Oleg

[Oleg Starodumov]

Post by Eric Margheim

Post by Eric Margheim
x yourdll!DllUnregisterServer
ln <address_of_DllUnregisterServer>+0xXXX

Ok. I've attached to the process but don't see where to put these commands
in. I tried in the command window but that's not working. Sorry for the
ignorance.

It should look like this:

1. File | Attach to Process, select the process, OK. (If asked to save workspace,
say no).

2. Open command window (if it is not yet open) (View | Command).

3. Wait until the edit line at the bottom of the command window becomes
accessible (it can take some time). Use it to enter commands.

If you enter a command, and it fails (an error message should be displayed),
post here the output. Also please tell WinDbg version (the latest (6.6.7.5) is recommended).

If none of the above helps, run the following command in _Windows_ command prompt
and post here the output:

cdb -pv -p <pid> -c "x yourdll!DllUnregisterServer;q"

(cdb.exe is located in the same directory with WinDbg; replace <pid> with the process id
of the target process, and specify the proper name of your dll)

Oleg

[Eric Margheim]

Post by Oleg Starodumov
1. File | Attach to Process, select the process, OK. (If asked to save workspace,
say no).
2. Open command window (if it is not yet open) (View | Command).
3. Wait until the edit line at the bottom of the command window becomes
accessible (it can take some time). Use it to enter commands.
If you enter a command, and it fails (an error message should be displayed),
post here the output. Also please tell WinDbg version (the latest
(6.6.7.5) is recommended).

OK. I think I was doing it right then. I get an error saying it doesn't
regonize "x yourdll!DllUnregisterServer" when I put that command in. Here
is the output:

0:023> x PRISMRptCom!DllUnregisterServer
^ Couldn't resolve 'x PRISMRptCom'


I am getting an error at the end of the initial load:

*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\ntdll.dll -

Post by Oleg Starodumov
If none of the above helps, run the following command in _Windows_ command prompt
cdb -pv -p <pid> -c "x yourdll!DllUnregisterServer;q"

I get the same error about resolving PRISMRptCom

Post by Oleg Starodumov
(cdb.exe is located in the same directory with WinDbg; replace <pid> with the process id
of the target process, and specify the proper name of your dll)
Oleg

[Oleg Starodumov]

Post by Eric Margheim
OK. I think I was doing it right then. I get an error saying it doesn't
regonize "x yourdll!DllUnregisterServer" when I put that command in. Here
0:023> x PRISMRptCom!DllUnregisterServer
^ Couldn't resolve 'x PRISMRptCom'

It means that this DLL is not loaded by the process.

You can print the list of loaded modules using 'lm' command.
Will your DLL be in the list?

Post by Eric Margheim
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\ntdll.dll -

It is not an error in fact, it simply means that symbols could not be loaded
for ntdll.dll. It will not affect the possibility to debug your DLL in this case,
but anyway you may want to set the symbol path to point to the public symbol server.
Then WinDbg will be able to download symbols for system DLLs.

http://www.debuginfo.com/articles/easywindbg.html#sympath

Oleg

[Eric Margheim]

Post by Oleg Starodumov

Post by Eric Margheim
OK. I think I was doing it right then. I get an error saying it doesn't
regonize "x yourdll!DllUnregisterServer" when I put that command in.
Here
0:023> x PRISMRptCom!DllUnregisterServer
^ Couldn't resolve 'x PRISMRptCom'

It means that this DLL is not loaded by the process.

Since I'm running under COM+ Applications (dllhost.exe) does the component
have to be in an active call when I run this? I'll try a long call to give
me time to jump in and see what happens.

Post by Oleg Starodumov
You can print the list of loaded modules using 'lm' command.
Will your DLL be in the list?

Post by Eric Margheim
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\ntdll.dll -

It is not an error in fact, it simply means that symbols could not be loaded
for ntdll.dll. It will not affect the possibility to debug your DLL in this case,
but anyway you may want to set the symbol path to point to the public symbol server.
Then WinDbg will be able to download symbols for system DLLs.
http://www.debuginfo.com/articles/easywindbg.html#sympath
Oleg

[Eric Margheim]

Post by Oleg Starodumov

Post by Eric Margheim
OK. I think I was doing it right then. I get an error saying it doesn't
regonize "x yourdll!DllUnregisterServer" when I put that command in.
Here
0:023> x PRISMRptCom!DllUnregisterServer
^ Couldn't resolve 'x PRISMRptCom'

It means that this DLL is not loaded by the process.
You can print the list of loaded modules using 'lm' command.
Will your DLL be in the list?

Nevermind. I just yesterday renamed the DLL to keep track of the ones I
was swapping in and out. It's PrismRptComR. LOL. OK that comes back
with an address on the left. I'll proceed.

Post by Oleg Starodumov

Post by Eric Margheim
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\ntdll.dll -

It is not an error in fact, it simply means that symbols could not be loaded
for ntdll.dll. It will not affect the possibility to debug your DLL in this case,
but anyway you may want to set the symbol path to point to the public symbol server.
Then WinDbg will be able to download symbols for system DLLs.
http://www.debuginfo.com/articles/easywindbg.html#sympath
Oleg

[Eric Margheim]

Post by Oleg Starodumov

Post by Eric Margheim
OK. I think I was doing it right then. I get an error saying it doesn't
regonize "x yourdll!DllUnregisterServer" when I put that command in.
Here
0:023> x PRISMRptCom!DllUnregisterServer
^ Couldn't resolve 'x PRISMRptCom'

It means that this DLL is not loaded by the process.
You can print the list of loaded modules using 'lm' command.
Will your DLL be in the list?

Post by Eric Margheim
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\ntdll.dll -

It is not an error in fact, it simply means that symbols could not be loaded
for ntdll.dll. It will not affect the possibility to debug your DLL in this case,
but anyway you may want to set the symbol path to point to the public symbol server.
Then WinDbg will be able to download symbols for system DLLs.

Ok I'm making some progress. Here is the output from what I've done in
WinDbg

0:011> x PRISMRptComR!DllUnregisterServer
*** WARNING: Unable to verify checksum for
E:\PrismDevelopment\ReleaseBuilds\PRISMRptCom\1.4.2.1\PrismBuilds\PRISMRptComR.dll
00959ef6 PRISMRptComR!DllUnregisterServer = <no type information>

So it looks like base address of the component is 00959ef6. So I then
added the offsets I see in Event Log to this for a few of the errors and got
the following

0:011> ln 98ceea
(0098bbdb) PRISMRptComR!CReportAccessorFuncs3::InitReportSetParms+0x130f
| (0098d032) PRISMRptComR!CReportAccessorFuncs3::Reschedule
0:011> ln 9694bb
(00968a52) PRISMRptComR!CReportAccessorFuncs3::GetRptRegistrySet+0xa69 |
(00969eea) PRISMRptComR!CReportAccessorFuncs3::DeleteDirContent
0:011> ln 32840
0:011> ln 32e40
0:011> ln 98cd36
(0098bbdb) PRISMRptComR!CReportAccessorFuncs3::InitReportSetParms+0x115b
| (0098d032) PRISMRptComR!CReportAccessorFuncs3::Reschedule
0:011> ln 98cedd
(0098bbdb) PRISMRptComR!CReportAccessorFuncs3::InitReportSetParms+0x1302
| (0098d032) PRISMRptComR!CReportAccessorFuncs3::Reschedule
0:011> ln 98617f
(00984a7c) PRISMRptComR!CReportAccessorFuncs3::UpdateReportStatus+0x1703
| (00987521) PRISMRptComR!CReportAccessorFuncs3::DistributeReports2

Next I ran my Release component under Debug in VS6 and then went to
disassembly and did a goto on those same addresses. They all seemed to be
in a bogus range. It would not allow me to go to source. I'm missing
something here.

[Oleg Starodumov]

Ok I'm making some progress. Here is the output from what I've done in WinDbg
0:011> x PRISMRptComR!DllUnregisterServer
*** WARNING: Unable to verify checksum for
E:\PrismDevelopment\ReleaseBuilds\PRISMRptCom\1.4.2.1\PrismBuilds\PRISMRptComR.dll
00959ef6 PRISMRptComR!DllUnregisterServer = <no type information>
So it looks like base address of the component is 00959ef6. So I then added the offsets I see in Event Log to this
for a few of the errors and got the following
0:011> ln 98ceea
(0098bbdb) PRISMRptComR!CReportAccessorFuncs3::InitReportSetParms+0x130f | (0098d032)
PRISMRptComR!CReportAccessorFuncs3::Reschedule
... Next I ran my Release component under Debug in VS6 and then went to disassembly and did a goto on those same
addresses. They all seemed to be in a bogus range. It would not allow me to go to source. I'm missing something
here.

Something is wrong with the DLL's symbols.

What will be the output of the following commands?

!sym noisy
.reload /f PRISMRptComR.dll
!lmi PRISMRptComR.dll

Oleg

[Eric Margheim]

Post by Oleg Starodumov

Ok I'm making some progress. Here is the output from what I've done in WinDbg
0:011> x PRISMRptComR!DllUnregisterServer
*** WARNING: Unable to verify checksum for
E:\PrismDevelopment\ReleaseBuilds\PRISMRptCom\1.4.2.1\PrismBuilds\PRISMRptComR.dll
00959ef6 PRISMRptComR!DllUnregisterServer = <no type information>
So it looks like base address of the component is 00959ef6. So I then
added the offsets I see in Event Log to this for a few of the errors and
got the following
0:011> ln 98ceea
(0098bbdb)
PRISMRptComR!CReportAccessorFuncs3::InitReportSetParms+0x130f |
(0098d032) PRISMRptComR!CReportAccessorFuncs3::Reschedule
... Next I ran my Release component under Debug in VS6 and then went to
disassembly and did a goto on those same addresses. They all seemed to
be in a bogus range. It would not allow me to go to source. I'm
missing something here.

Something is wrong with the DLL's symbols.
What will be the output of the following commands?
!sym noisy
.reload /f PRISMRptComR.dll
!lmi PRISMRptComR.dll
Oleg

Ok I'm making some progress. Here is the output from what I've done in
WinDbg
0:011> x PRISMRptComR!DllUnregisterServer
*** WARNING: Unable to verify checksum for
E:\PrismDevelopment\ReleaseBuilds\PRISMRptCom\1.4.2.1\PrismBuilds\PRISMRptComR.dll
00959ef6 PRISMRptComR!DllUnregisterServer = <no type information>
So it looks like base address of the component is 00959ef6. So I then
added the offsets I see in Event Log to this for a few of the errors and
got the following
0:011> ln 98ceea
(0098bbdb) PRISMRptComR!CReportAccessorFuncs3::InitReportSetParms+0x130f
| (0098d032) PRISMRptComR!CReportAccessorFuncs3::Reschedule
... Next I ran my Release component under Debug in VS6 and then went to
disassembly and did a goto on those same addresses. They all seemed to
be in a bogus range. It would not allow me to go to source. I'm missing
something here.

Something is wrong with the DLL's symbols.
What will be the output of the following commands?
!sym noisy
.reload /f PRISMRptComR.dll
!lmi PRISMRptComR.dll

Looks like the symbol path is off. I'll try to use the .symfix command as
they recommend.
*** wait with pending attach
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path. *
* Use .symfix to have the debugger choose a symbol path. *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is:
WARNING: Process 3352 is not attached as a debuggee
The process can be examined but debug events will not be received
....................................................................................
Loading unloaded module list
..
(d18.1784): Wake debugger - code 80000007 (first chance)
eax=0007fd08 ebx=00000000 ecx=75c5d060 edx=75c5d084 esi=00000040
edi=00000000
eip=7c82ed54 esp=0007fcd8 ebp=0007fd48 iopl=0 nv up ei ng nz ac pe cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000297
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\ntdll.dll -
ntdll!KiFastSystemCallRet:
7c82ed54 c3 ret
0:000> !sym noisty
!sym <noisy/quiet - prompts/prompts off> - quiet mode - symbol prompts on
0:000> .reload /f PRISMRptComR.dll
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
*********************************************************************
0:000> !lmi PRISMRptComR.dll
Loaded Module Info: [prismrptcomr.dll]
Module: PRISMRptComR
Base Address: 00950000
Image Name:
E:\PrismDevelopment\ReleaseBuilds\PRISMRptCom\1.4.2.1\PrismBuilds\PRISMRptComR.dll
Machine Type: 332 (I386)
Time Stamp: 44f6f578 Thu Aug 31 09:43:04 2006
Size: d1000
CheckSum: 0
Characteristics: 210e
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 7e, 0, cf000 [Debug data not mapped] - Can't validate symbols, if
present.
Symbol Type: DEFERRED - No error - symbol load deferred
Load Report: no symbols loaded>

[Oleg Starodumov]

Please create c:\symbols directory (you can use other dir name if necessary)
and try again the following commands:

.symfix c:\symbols
!sym noisy
.reload /f PRISMRptComR.dll
!lmi PRISMRptComR.dll

(note that '!sym noisy' was entered incorrectly at the previous attempt)

Oleg

[Eric Margheim]

Post by Oleg Starodumov
Please create c:\symbols directory (you can use other dir name if necessary)
.symfix c:\symbols
!sym noisy
.reload /f PRISMRptComR.dll
!lmi PRISMRptComR.dll
(note that '!sym noisy' was entered incorrectly at the previous attempt)

0:011> !sym noisy
noisy mode - symbol prompts on
0:011> .symfix c:\symbols
DBGHELP: Symbol Search Path:
SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
0:011> .reload /f PRISMRptComR.dll
SYMSRV: c:\symbols\PRISMRptCom.pdb\44F461E62\PRISMRptCom.pdb not found
SYMSRV:
http://msdl.microsoft.com/download/symbols/PRISMRptCom.pdb/44F461E62/PRISMRptCom.pdb
not found
*** WARNING: Unable to verify checksum for
E:\PrismDevelopment\ReleaseBuilds\PRISMRptCom\1.4.2.1\PrismBuilds\PRISMRptComR.dll
DBGHELP: PRISMRptComR - private symbols & lines
E:\PrismDevelopment\ReleaseBuilds\PRISMRptCom\1.4.2.1\PrismBuilds\PRISMRptCom.pdb
0:011> !lmi PRISMRptComR.dll
Loaded Module Info: [prismrptcomr.dll]
Module: PRISMRptComR
Base Address: 00950000
Image Name:
E:\PrismDevelopment\ReleaseBuilds\PRISMRptCom\1.4.2.1\PrismBuilds\PRISMRptComR.dll
Machine Type: 332 (I386)
Time Stamp: 44f6f578 Thu Aug 31 09:43:04 2006
Size: d1000
CheckSum: 0
Characteristics: 210e
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 7e, 0, cf000 [Debug data not mapped] - Can't
validate symbols, if present.
Image Type: FILE - Image read successfully from debugger.
E:\PrismDevelopment\ReleaseBuilds\PRISMRptCom\1.4.2.1\PrismBuilds\PRISMRptComR.dll
Symbol Type: PDB - Symbols loaded successfully from image path.
E:\PrismDevelopment\ReleaseBuilds\PRISMRptCom\1.4.2.1\PrismBuilds\PRISMRptCom.pdb
Compiler: Linker - front end [0.0 bld 0] - back end [6.0 bld 8447]
Load Report: private symbols & lines, not source indexed
E:\PrismDevelopment\ReleaseBuilds\PRISMRptCom\1.4.2.1\PrismBuilds\PRISMRptCom.pdb

[Oleg Starodumov]

This time symbols look correct, so 'x' and 'ln' should work,
at least for the first function on the call stack that belongs to this DLL.

If the results are still incorrect, there can be various reasons. E.g.:
- the version of the DLL that is loaded into debugger is not the same as
the one the call stack was taken for (it must be exactly the same build)
- if some modules precede your DLL on the call stack, and they are
built with FPO optimization, the whole call stack can be incorrect
(in this case, correct results (for the approach we are trying to use) can be achieved
usually only if the application was running on XP-SP2 and 2003-SP1)

Minidumps are not subject to all these issues, and usually always give
correct call stacks in such situations.

Oleg

[Eric Margheim]

Post by Oleg Starodumov
This time symbols look correct, so 'x' and 'ln' should work,
at least for the first function on the call stack that belongs to this DLL.
- the version of the DLL that is loaded into debugger is not the same as
the one the call stack was taken for (it must be exactly the same build)
- if some modules precede your DLL on the call stack, and they are
built with FPO optimization, the whole call stack can be incorrect
(in this case, correct results (for the approach we are trying to use) can be achieved
usually only if the application was running on XP-SP2 and 2003-SP1)
Minidumps are not subject to all these issues, and usually always give
correct call stacks in such situations.

Ok for minidumps does this require new coding in the dll?

I have insured the versions are the same so hopefully the next error will
confirm this. For the past 2 days they haven't had any errors but I've
been running a debug build on there so that would be logical considering
that these types of errors often slip through in debug builds.

We are running 2003 SP1

[Eric Margheim]

Got an error with the new build in production. I had the pdb file out there
too so call stack tells me the following:

Call Stack:
MFC42!Ordinal6585 + 0x82
MFC42!Ordinal1585 + 0x3f
MFC42!Ordinal2027 + 0x1a
MFC42!Ordinal2028 + 0xb5
MFC42!Ordinal939 + 0x1e
PRISMRptCom!CReportAccessorFuncs3::SendSimpleMsgNoLogging(struct tagVARIANT
*,class CString,class CString,class CString,struct _Recordset * *) + 0x240
PRISMRptCom!CReportAccessorFuncs3::UpdateReportStatus(struct tagVARIANT
*,unsigned short * *,unsigned short * *,struct _Recordset * *) + 0x2a49
PRISMRptCom!CReportAccessorFuncs::UpdateReportStatus(struct tagVARIANT
*,unsigned short * *,unsigned short * *) + 0x39
PRISMRptCom!CReportAccessor::UpdateReportStatus(struct tagVARIANT *,unsigned
short * *,unsigned short * *) + 0x33
RPCRT4!NdrServerInitialize + 0x462
RPCRT4!NdrStubCall2 + 0x217
RPCRT4!CStdStubBuffer_Invoke + 0x82
OLEAUT32!VariantTimeToDosDateTime + 0x1827
ole32!WdtpInterfacePointer_UserMarshal + 0x13fa
ole32!WdtpInterfacePointer_UserMarshal + 0x13ad
ole32!ProgIDFromCLSID + 0x1fd3
ole32!ProgIDFromCLSID + 0x1dd1
ole32!WdtpInterfacePointer_UserMarshal + 0x1e5f
ole32!WdtpInterfacePointer_UserMarshal + 0x116c
ole32!WdtpInterfacePointer_UserMarshal + 0x1e6f
RPCRT4!I_RpcGetBuffer + 0x1d8
RPCRT4!I_RpcGetBuffer + 0x159
RPCRT4!I_RpcGetBuffer + 0x7f
RPCRT4!NdrConformantArrayMemorySize + 0x558
RPCRT4!MesEncodeIncrementalHandleCreate + 0xadc
RPCRT4!NdrSimpleStructMemorySize + 0x12ac
RPCRT4!NdrSimpleStructMemorySize + 0x138c
RPCRT4!NdrSimpleStructMemorySize + 0x1224
RPCRT4!NdrSimpleStructMemorySize + 0xbec
RPCRT4!NdrSimpleStructMemorySize + 0xc2d
RPCRT4!NdrSimpleStructMemorySize + 0x8de
RPCRT4!I_RpcTransGetThreadEvent + 0x39c
RPCRT4!I_RpcTransGetThreadEvent + 0x188
RPCRT4!I_RpcLogEvent + 0xe92
kernel32!GetModuleFileNameA + 0xeb

Post by Oleg Starodumov
This time symbols look correct, so 'x' and 'ln' should work,
at least for the first function on the call stack that belongs to this DLL.
- the version of the DLL that is loaded into debugger is not the same as
the one the call stack was taken for (it must be exactly the same build)
- if some modules precede your DLL on the call stack, and they are
built with FPO optimization, the whole call stack can be incorrect
(in this case, correct results (for the approach we are trying to use) can be achieved
usually only if the application was running on XP-SP2 and 2003-SP1)
Minidumps are not subject to all these issues, and usually always give
correct call stacks in such situations.
Oleg

[Eric Margheim]

OK So how do I now take this info with function name + offset and get the
exact line?

I'm still struggling with that part.

Thanks

[Oleg Starodumov]

Post by Eric Margheim
OK So how do I now take this info with function name + offset and get the
exact line?

1. Load the application into VC debugger (so that exactly the same build
of the DLL is loaded). Ensure that the DLL's symbols are loaded.

2. Look up the target function (SendSimpleMsgNoLogging) in sources.
R-click anywhere in the function's source and choose Go to Disassembly.

3. Determine the address mentioned on the call stack (add the offset
to the start address of the function, which can be found in Disassembly window).

4. In Disassembly window, R-click on that address and choose Go to Source.

Note that if the DLL was built with optimizations, source information
will not necessarily be correct (but should be close enough).

Oleg

[Eric Margheim]

Post by Oleg Starodumov

Post by Eric Margheim
OK So how do I now take this info with function name + offset and get the
exact line?

1. Load the application into VC debugger (so that exactly the same build
of the DLL is loaded). Ensure that the DLL's symbols are loaded.
2. Look up the target function (SendSimpleMsgNoLogging) in sources.
R-click anywhere in the function's source and choose Go to Disassembly.
3. Determine the address mentioned on the call stack (add the offset
to the start address of the function, which can be found in Disassembly window).
4. In Disassembly window, R-click on that address and choose Go to Source.
Note that if the DLL was built with optimizations, source information
will not necessarily be correct (but should be close enough).
Oleg

Thanks I will report back after trying this sir.

[Eric Margheim]

Post by Oleg Starodumov

Post by Eric Margheim
OK So how do I now take this info with function name + offset and get the
exact line?

1. Load the application into VC debugger (so that exactly the same build
of the DLL is loaded). Ensure that the DLL's symbols are loaded.

Loaded 'c:\windows\system32\dllhost.exe', no matching symbolic information
found.
Loaded 'ntdll.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\kernel32.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\msvcrt.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\ole32.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\advapi32.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\rpcrt4.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\gdi32.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\user32.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\shimeng.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\apphelp.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\clbcatq.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\comres.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\oleaut32.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\version.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\ntmarta.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\samlib.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\wldap32.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\xpsp2res.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\nview.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\shlwapi.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\shell32.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\psapi.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\winmm.dll', no matching symbolic information
found.
Loaded
'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.1830_x-ww_7AE38CCF\comctl32.dll',
no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\rdpsnd.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\winsta.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\netapi32.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\comsvcs.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\rsaenh.dll', no matching symbolic information
found.
The thread 0x980 has exited with code 0 (0x0).
Loaded 'C:\WINDOWS\system32\odbc32.dll', no matching symbolic information
found.
Loaded
'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.3790.1830_x-ww_1B6F474A\comctl32.dll',
no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\comdlg32.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\odbcint.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\system32\es.dll', no matching symbolic information found.
The thread 0x15C4 has exited with code 0 (0x0).

Post by Oleg Starodumov
2. Look up the target function (SendSimpleMsgNoLogging) in sources.
R-click anywhere in the function's source and choose Go to Disassembly.

Nothing happens when I choose the Go to Disassembly option. I have the
Release version running in debug under dllhost.exe like I typically do to
debug components.

Post by Oleg Starodumov
3. Determine the address mentioned on the call stack (add the offset
to the start address of the function, which can be found in Disassembly window).
4. In Disassembly window, R-click on that address and choose Go to Source.
Note that if the DLL was built with optimizations, source information
will not necessarily be correct (but should be close enough).
Oleg

[Oleg Starodumov]

Post by Oleg Starodumov
2. Look up the target function (SendSimpleMsgNoLogging) in sources.
R-click anywhere in the function's source and choose Go to Disassembly.

Nothing happens when I choose the Go to Disassembly option. I have the Release version running in debug under
dllhost.exe like I typically do to debug components.

Do you see your DLL in the list of symbols-related messages? I do not.
Was it loaded by the process, in fact? (check in Modules window)

Oleg

[Eric Margheim]

Post by Oleg Starodumov

Post by Eric Margheim

Post by Oleg Starodumov
2. Look up the target function (SendSimpleMsgNoLogging) in sources.
R-click anywhere in the function's source and choose Go to Disassembly.

Nothing happens when I choose the Go to Disassembly option. I have the
Release version running in debug under dllhost.exe like I typically do to
debug components.

Do you see your DLL in the list of symbols-related messages? I do not.
Was it loaded by the process, in fact? (check in Modules window)

It's not in there but it's what I'm debugging so that doesn' t make sense.
Here's what I'm doing.

I put the Release DLL into a COM+ Application
I then start a debug session from within VC6 for the same DLL code making
dllhost.exe the debug app.
It waits in debug mode fine.

If I run a debug version of the DLL and put in a break point, I can see the
source code when the break point is hit and execution is paused.

[Eric Margheim]

Post by Oleg Starodumov

Ok I'm making some progress. Here is the output from what I've done in WinDbg
0:011> x PRISMRptComR!DllUnregisterServer
*** WARNING: Unable to verify checksum for
E:\PrismDevelopment\ReleaseBuilds\PRISMRptCom\1.4.2.1\PrismBuilds\PRISMRptComR.dll
00959ef6 PRISMRptComR!DllUnregisterServer = <no type information>
So it looks like base address of the component is 00959ef6. So I then
added the offsets I see in Event Log to this for a few of the errors and
got the following
0:011> ln 98ceea
(0098bbdb)
PRISMRptComR!CReportAccessorFuncs3::InitReportSetParms+0x130f |
(0098d032) PRISMRptComR!CReportAccessorFuncs3::Reschedule
... Next I ran my Release component under Debug in VS6 and then went to
disassembly and did a goto on those same addresses. They all seemed to
be in a bogus range. It would not allow me to go to source. I'm
missing something here.

Something is wrong with the DLL's symbols.
What will be the output of the following commands?
!sym noisy
.reload /f PRISMRptComR.dll
!lmi PRISMRptComR.dll

I put my .pdb file in the folder that WinDbg is running and that seemed to
get rid of the error. The line numbers, etc, are still the same. I'm
uploading the exact same dll and pdb to a server where I'll likely get more
errors. This will make sure that we are dealing with the exact same
version. I'm assuming renaming the file makes no different.