Help with Unhandled Exception in Outlook Add-in

M

MikeJohnson

Please help me determine the cause of an unhandled exception
in my C++-based Outlook add-in.
I am using C++ smart pointers, as generated in "msoutli.tli".

I get:
"Unhandled Exception C0000005 Access Violation reading 007500b6"


Here is the C++ generated source, from "msoutl.tli":

inline HRESULT Attachment::SaveAsFile ( _bstr_t Path ) {
HRESULT _hr = raw_SaveAsFile(Path);
if (FAILED(_hr)) _com_issue_errorex(_hr, this, __uuidof(this));
return _hr;
}

The crash is occurring in raw_SaveAsFile.

Here is the disassembly of the line where the exception occurs:

HRESULT _hr = raw_SaveAsFile(Path);
0745456F lea ecx,[Path]
07454572 call _bstr_t::blush:perator unsigned short * (7417CA8h)
07454577 mov esi,esp
07454579 push eax
0745457A mov eax,dword ptr [this]
0745457D mov ecx,dword ptr [eax]
0745457F mov edx,dword ptr [this]
07454582 push edx
07454583 call dword ptr [ecx+54h]

My Path variable looks okay, I think:

m_Data: 0x074d84b0
{
m_wstr=0x00203604 "C:\Program Files\as\Backup\Deleted
Items\filename.txt"
m_mstr=0x00000000 <Bad Ptr>
m_RefCount: 2
}


The "call dword ptr [ecx+54h]" is causing the unhandled exception,
because ecx + 54h = 007500b6 (the address that can't be accesssed).

Why is the target of the call messed up?

FYI,
here is the rest of the disassembly of "HRESULT _hr =
raw_SaveAsFile(Path);",
after the call dword ptr[ecx+54h]:

07454586 cmp esi,esp
07454588 call @ILT+5875(__RTC_CheckEsp) (74186F8h)
0745458D mov dword ptr [_hr],eax


Thanks very very much for any assistance!!

I will leave the debugger open,
in case more information would be helpful.

Thank you,
Mike
 
H

Henry Gusakovsky

it seems that 'this' pointer is currupted.
See additional comments below.

MikeJohnson said:
Please help me determine the cause of an unhandled exception
in my C++-based Outlook add-in.
I am using C++ smart pointers, as generated in "msoutli.tli".

I get:
"Unhandled Exception C0000005 Access Violation reading 007500b6"


Here is the C++ generated source, from "msoutl.tli":

inline HRESULT Attachment::SaveAsFile ( _bstr_t Path ) {
HRESULT _hr = raw_SaveAsFile(Path);
if (FAILED(_hr)) _com_issue_errorex(_hr, this, __uuidof(this));
return _hr;
}

The crash is occurring in raw_SaveAsFile.

Here is the disassembly of the line where the exception occurs:

HRESULT _hr = raw_SaveAsFile(Path);
0745456F lea ecx,[Path]
07454572 call _bstr_t::blush:perator unsigned short * (7417CA8h)
07454577 mov esi,esp
07454579 push eax
0745457A mov eax,dword ptr [this] ;
now eax contain address of the object instance
0745457D mov ecx,dword ptr [eax]
now ecx contain address of virtual functions table
0745457F mov edx,dword ptr [this]
now edx contain address of the object instance
07454582 push edx
first parameter for STD virtual function is pointer to the object
07454583 call dword ptr [ecx+54h] //that calling virtual function
raw_SaveAsFile

So check pointer when you first obtain Attachment object instance
and compare it with value inside raw_SaveAsFile call.
My Path variable looks okay, I think:

m_Data: 0x074d84b0
{
m_wstr=0x00203604 "C:\Program Files\as\Backup\Deleted
Items\filename.txt"
m_mstr=0x00000000 <Bad Ptr>
m_RefCount: 2
}


The "call dword ptr [ecx+54h]" is causing the unhandled exception,
because ecx + 54h = 007500b6 (the address that can't be accesssed).

Why is the target of the call messed up?

FYI,
here is the rest of the disassembly of "HRESULT _hr =
raw_SaveAsFile(Path);",
after the call dword ptr[ecx+54h]:

07454586 cmp esi,esp
07454588 call @ILT+5875(__RTC_CheckEsp) (74186F8h)
0745458D mov dword ptr [_hr],eax


Thanks very very much for any assistance!!

I will leave the debugger open,
in case more information would be helpful.

Thank you,
Mike
WBR
Henry
 
M

MikeJohnson

Hi Henry,

Thanks very much for your reply!

I just spent a few hours stepping through this code with the debugger.

I think you may be on the right track.

I notice after *every* call through the virtual function

call dword ptr [ecx+54h] //that calling virtual function

All the virtual function pointer values of *this change, and sometimes
the __vfptr changes also.
Should the method Attachment::SaveAsFile be modifying its invoking
object?

I also found this post, about a year old, from someone who experienced
SaveAsFile crashing
intermittently:

http://groups-beta.google.com/group...c50283c6a?q=SaveAsFile+crash#4871ffdc50283c6a

If this is a bug in outlib.dll, I'm suprised no one else has been
bitten!

Perhaps I'm missing something?

Thanks again,
Mike
 
H

Henry Gusakovsky

MikeJohnson said:
Hi Henry,

Thanks very much for your reply!

I just spent a few hours stepping through this code with the debugger.

I think you may be on the right track.

I notice after *every* call through the virtual function

call dword ptr [ecx+54h] //that calling virtual function

All the virtual function pointer values of *this change, and sometimes
the __vfptr changes also.
if __vfptr changes that means that object pointer represents different
interface.
so maybe that is the problem.

Should the method Attachment::SaveAsFile be modifying its invoking
object?
You can set breakpoint on memory modification and see where it happens.
I also found this post, about a year old, from someone who experienced
SaveAsFile crashing
intermittently:

http://groups-beta.google.com/group...c50283c6a?q=SaveAsFile+crash#4871ffdc50283c6a

If this is a bug in outlib.dll, I'm suprised no one else has been
bitten!
Before blame outlib.dll you chould check every statement of your code to
make sure that bug is not yours.
Every time crash occurs first of all i think that there is a mistake in the
my code. The mistake may be far away frome where it crashes.
Perhaps I'm missing something?
who knows.
You can post some more details about code.
Thanks again,
Mike

WBR
Henry
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top