Debugging an access violation

Question

I'm using a large closed-source framework. I recently added a new entity, and now I'm getting access violations when performing some actions. However, they occur on calls from within the framework, so I don't know what I've implemented wrong, since I don't get a call stack.

The violation is reported in the function _CRTIMP PFLS_GETVALUE_FUNCTION __cdecl __set_flsgetvalue() defined in the CRT file tidtable.c. The specific row is PFLS_GETVALUE_FUNCTION flsGetValue = FLS_GETVALUE;. I'm not sure, but I think it is related to function pointers?

The error message is Unhandled exception at 0x0000007a in fmwk.exe: 0xC0000005: Access violation reading location 0x0000007a.. My interpretation is that it's attempting to access something at offset 0x7a into an object, but it's acually given a null pointer. Is this correct? If it is, is there a way of finding what that offset corresponds to?

Below is the call stack:

0000007a()  
fmwk.dll!100f2630()     
[Frames below may be incorrect and/or missing, no symbols loaded for fmwk.dll]  

<lots of framework and windows dlls>

fmwk.exe!00402ef4()     
msvcr100.dll!__set_flsgetvalue()  Line 145 + 0xc bytes  C
msvcr100.dll!_getptd_noexit()  Line 498 + 0x7 bytes C
msvcr100.dll!_getptd()  Line 523 + 0x5 bytes    C
msvcr100.dll!_LocaleUpdate::_LocaleUpdate(localeinfo_struct * plocinfo=0x00000000)  Line 243 + 0x5 bytes    C++
msvcr100.dll!x_ismbbtype_l(localeinfo_struct * plocinfo=0x00000000, unsigned int tst=0, int cmask=1386664, int kmask=1414714)  Line 219 C++
msvcr100.dll!_ismbblead(unsigned int tst=0)  Line 172 + 0xe bytes   C++
fmwk.exe!004010a0()     
fmwk.exe!00404d61()     
kernel32.dll!7c817077()     

Solution

Use Application Verifier to debug this access violation. It should stop execution earlier when bad thing happens with better call stack than this one.

Looks like you dereferenced NULL pointer somewhere but program did not crash immediately since it is Undefined Behaviour, continued executing and crashed a bit later with weird call stack.

Comments

[carlpett]

Oh I'm pretty sure the fault is mine. Adding new functionality requires quite a lot of code, and it is all added at once. I've re-read all my code a few times and can't spot any errors, but I'm guessing I missed initializing some function pointer member which is inherited (the framework has it's own class emulation, written in C).

[carlpett]

It seems like a nice program, thanks for the tip. However, either I don't understand it, or it cannot help me. It triggers a break, but the call stack doesn't help here either. The only examinable frames are from Application Verifier itself, and the data availible is just an error message "first chance access violation for current stack trace".

[ks1322]

You have to load debug symbols of close-source framework to get helpful call stack. Do you have them?

[carlpett]

Nope. And I seriously doubt I will be able to get them either :(

[carlpett]

I'll accept this, not because it solved my problem, but because it should have :) (I could not get anywhere with the problem, and it was decided to chuck it out and use another class)