Help with Unhandled Exception in Outlook Add-in

  • Thread starter Thread starter MikeJohnson
  • Start date Start date
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::operator 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
 
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::operator unsigned short * (7417CA8h)
07454577 mov esi,esp
07454579 push eax
0745457A mov eax,dword ptr [this] ;
Click to expand...
now eax contain address of the object instance
0745457D mov ecx,dword ptr [eax]
Click to expand...
now ecx contain address of virtual functions table
0745457F mov edx,dword ptr [this]
Click to expand...
now edx contain address of the object instance
07454582 push edx
Click to expand...
first parameter for STD virtual function is pointer to the object
07454583 call dword ptr [ecx+54h] //that calling virtual function
Click to expand...
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
Click to expand...
WBR
Henry
 
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
 
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.
Click to expand...
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?
Click to expand...
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!
Click to expand...
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?
Click to expand...
who knows.
You can post some more details about code.
Thanks again,
Mike
Click to expand...

WBR
Henry
 
Back
Top