Hello,

The release build of my dll crashes when I run its calling exe within the
debugger. If I start the exe from the command line, everything behaves as
expected. The debug build runs as expected, both in and outside of the
debugger.

The crash seems to occur when a local variable (a pointer) goes out of
scope.

Any suggestions on how to attack a problem like this?

TIA

CB

"Unhandled exception at 0x77f75a58 in xxxx.exe: user breakpoint".
This is plain C++.
Looking at the call stack, it looks like our memory manager is being called
to free what I expect to be a stack variable -- a locally-declared pointer.
I added /GS, but it did not seem to make any difference.

What would make this problem appear when the .exe is run from the debugger,
but not when the .exe is started from the command line?

Thenks for your reply.


[quoted text, click to view]

Hi,

Do you have the detail error message on the crach?

Is your DLL a pure C++ or a MC++ program, if it is not a MC++, we suggest
you can add the /GS compiler option to your DLL project's Release build
configuration to test again...


Thanks!

Best regards,

Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

Hi,

I agree with you, the problem appears to be caused by a memory error, we
suggest you can use the following utility to troubleshoot your program:

SAMPLE: PageHeap1.exe Finds Heap Corruption and Memory Errors
http://support.microsoft.com/?id=264471



Thanks!

Best regards,

Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

[quoted text, click to view]

When an application is started under debugger, Win32 heap activates some
additional debugging features. For example, it checks that the pointer passed
to HeapFree does really belong to the given heap, and raises a hard-coded
breakpoint if it does not.

When the application is not started under debugger, the problem does probably
still exist and silently corrupts the heap, which still can affect the application
some time later.

Regards,
Oleg

Thanks, Gary. While PageHeap1 didn't reveal anything, I found the problem.

[quoted text, click to view]

I spoke too soon... The problem has reappeared. My application is a client
to servers serving xml. It only happens with some servers.
I'm baffled about why it is the release build (w/ or w/o debug symbols, but
w/ _DEBUG not defined) and only when started in the debugger.


[quoted text, click to view]

I read his comments, and believe that is a possibility (that HeapFree is
called with a pointer that wasn't allocated from that heap). The problems
are: 1) determining that it is, indeed, happening; and 2) finding out where
in my program -- in the dll or the caller -- it is happening.
I am trying to use pageheap.exe. When I run it from the command line
(pageheap /enable myapp.exe), then run myapp.exe, everything runs as
expected.

As I said in an earlier message, what I see in the call stack at the time of
the crash is myFunc() calling our ffree() which eventually calls
msvcr71.dll!free(). The important point is that our ffree() is being given
the address of a locally-declared pointer. I would expect that to be on the
stack. Why our memory manager is being called to free something we didn't
allocate is confusing.

Thanks for your help.
CB

[quoted text, click to view]

Hi,

Do you have reviewed the reply of the community member Oleg Starodumov, I
think he gave a valuble hint on this scenario, does your program have such
problem he described?


Thanks!

Best regards,

Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

Hi,

Thanks for your reponse!

[quoted text, click to view]
of the crash is myFunc() calling our ffree() which eventually calls
msvcr71.dll!free(). The important point is that our ffree() is being given
the address of a locally-declared pointer. I would expect that to be on
the stack. Why our memory manager is being called to free something we
didn't allocate is confusing.
[quoted text, click to view]

Can you locate the corresponding code in your program, and would you please
post it in the group?
maybe we can find something from it...


Thanks!

Best regards,

Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

bool RayGun::GetFeatures(
long numColumns,
KillerAllType** ppATArray,
RayGunImportCB* pCBFns,
bool bUseExistingTNT,
const TCHAR* pFilename)
{
bool bOK = false;
if (bUseExistingTNT && m_bTNTFileExists) {
}
else {
GetTNT(bUseExistingTNT, pFilename);
}

if (m_bTNTFileExists) {
const TNTInfoEx * pWepInfoEx = 0; // The address of this var
is passed to our memory manager to free
mtl::vector<const TNTInfoEx *> vectRayGunInfoEx;

if (0 == m_pWFSGetFtrRdr) {
m_pRGGetFtrRdr = RGGetFeatureReader::Create();
}

for (unsigned int colCnt = 0; colCnt < GetColumnCount(); ++colCnt) {
GetRayGunInfo(pWepInfoEx, colCnt);
vectRayGunInfoEx.push_back(pWepInfoEx);
}

// process TNT file
if (m_pRGGetFtrRdr->Load(m_TNTFile, &vectRayGunInfoEx, m_pCSys)) {
if (m_pRGGetFtrRdr->GetRecords(GetWaveLength(), ppATArray, pCBFns)) {
bOK = true;
}
}

// clean up
vectRayGunInfoEx.erase(vectRayGunInfoEx.begin(), vectRayGunInfoEx.end());
RGGetFeatureReader::Destroy(m_pRGGetFtrRdr); m_pRGGetFtrRdr = 0;

if (!bOK) {
SetError(ERRLEVEL_SEVERE, ERR_RG_BAD_TNT_PROCESSING,
ERRSTR_RG_BAD_TNT_PROCESSING);
}

}

return bOK;
}

[quoted text, click to view]

Hi,

Thanks for your code snippet, it seems OK.

However, how about the TNTInfoEx, is it a class, would you please post its
definition as well as the implementation of the function GetRayGunInfo if
it is not inconvenience?


Thanks!

Best regards,

Gary Chang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

Hi,

Additionally, does this crash happens all the time or just in some specific
scenario?

If it is the second situation, could you find what is the callee of the
ffree() function? and where does the object(the pointer referenced) which
passed to the ffree() come from, is it created on heap or stack, is it
already deleted?


Thanks!

Best regards,

Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------