We help IT Professionals succeed at work.

Debuger crash when inserting BYTE count into table

decornez asked
Medium Priority
Last Modified: 2012-06-27

I have a DLL that runs in release mode but that crashes when trying to use the debug mode.

The line it crashes on is as follows:

func[nFuncs][i][0] =  (BYTE) strlen(func[nFuncs][i]+1);

The func table looks like this:

static LPSTR func[][19]

I use Excel.exe as the executable for the debug session.

The error message I get is:

"Unhandled exception in EXCEL.EXE (TEST.XLL) 0xC0000005: Access Violation"

Any idea?

Watch Question

If program crashes in Debug mode, debug it. Set breakpoint to this line and see what happens.

Are you sure you have something alocated at (func[nFuncs][i]+1)?


That's what I did, but nothing I can use to fix the problem.

The debug window shows:

func[nfuncs][i]                                             0x03fb3fd0 " ThisCell"
func[nfuncs][i][0]                                         32   '    '
i                                                                 0
strlen returned                                             <void>

Not sure what to make of this unfortunately...
Looks like first string is read properly.
Looks like the octal count of this string is not stored properly in func[nfuncs][i][0] since it shows 32   '    '.
Otherwise i ok, and strlen returned ok as well.


Yes, for example the first string when looping through the table is recognized as " This Cell" by the debugger.

Maybe func[nfuncs][i]  points to read-only memoty (like string literal)?
What happens if you change this code by the following way:

int n = strlen(func[nFuncs][i]+1);
func[nFuncs][i][0] =  (BYTE) n;


I've tried and get the same error.


Not sure if it helps, but the disassembly code looks like this:

03F62997   mov         eax,[nFuncs (03fd13a8)]
03F6299C   imul        eax,eax,4Ch
03F6299F   mov         ecx,dword ptr [ebp-4]
03F629A2   mov         edx,dword ptr [eax+ecx*4+3FC7028h]
03F629A9   mov         al,byte ptr [a]
03F629AC   mov         byte ptr [edx],al

The violation is on the last line.
What is the contents of func[nFuncs][i]+1. Can you output the string somehow?

Where did you allocate the func[0][0] storage? Is there any chance that this storage has been deleted somewhere else? You should think of multi-threading where one thread allocates storage, passes the pointer to a second thread that calls your function while in the meantime the first thread terminated and freed the storage.

What debugger you are using? With VC Debugger you may get the last executed statement by doing that:

  - Start Debugger and set a break point before crash.
  - Select Exceptions... in Debug Menu and hilite Access Violation in Exception List. Then check 'Stop Always' in radio box
  - Run to Crash
  - Look at stack window (you may get it by right-clicking somewhere in menu area) and evaluate the top-most function that shows
    C++ code. if the variables window shows funny pointers like 0xcdcdcdcd or 0xeeeeffff the memory had been deleted somewhere
  - Or if you see code telling something like _bNoMansLandFill or nNoMansLandSize you try to write outside allocated memory.

Hope, that helps


Sorry, I was away for a few days.

func[0][0] is a hard coded string that does not change.
When running the debugger I can see the string no problem before it crashes. So it does not seem to be the source of the crash.

On the other hand, when I step into the program with the debugger, it opens a "Find Source" dialog box looking for a file called STRLEN.ASM ??? Not sure what's going on here.

Otherwise I have tried your debugger approach but the pointers look ok. I get the following:

--- intel\strlen.asm  ---------------------------
03EC24A0   mov         ecx,dword ptr [esp+4]
03EC24A4   test        ecx,3
03EC24AA   je          main_loop (03ec24c0)

The debugger seems to be stuck on:
03EC24A0   mov         ecx,dword ptr [esp+4]

Otherwise, I did not see the code telling me something like _bNoMansLandFill or nNoMansLandSize, so it looks like I am not trying to write outside the allocated memory.

So in the end, for some reason it looks like the problem comes from the fact that the debugger cannot find the STRLEN.ASM file. Any idea how to fix this?


The STRLEN.ASM is just for debugging, doesn't crash from it. It's the asm source for strlen(..) function.
Are you sure that func[nfuncs][i] ends with a NULL character? Try some other method to count the size, like lstrlen(..) function or 'by hand' in a for-loop.

And strlen.asm should be here :
"VISUAL_STUDIO.NET_DIR\Vc7\crt\src\intel\strlen.asm" for vc7
>> strlen(func[nFuncs][i]+1);

If this call crashes the address (func[nFuncs][i]+1) is invalid, i. e. outside of address space.

So you should debug using Quick Watch
    - address of func[nFuncs][i]
    - address of func[nFuncs][i] + 1
    - (char*)(func[nFuncs][i] + 1)       // enter this to Quick Watch and reevaluate value
    - nFunc
    - i

and tell us the results.

Regards, Alex


I have tried lstrlen and sizeof already, but to no avail.
The string is null terminated.
After pointing to the STRLEN.ASM file, I now get a new error message:

First-chance exception in EXCEL.EXE (NTDLL.DLL): 0xC0000005: Access Violation.

In the disassembly window, it points to the following code when crashing:

77F9CEC6   cmp         byte ptr [ebx+4],0FFh

Forget that disassembly of strlen assembler code.

strlen isn't corrupt but the address it got from the calling function.

There are two possibilities:

1. The address of (func[nFuncs][i] + 1) points to invalid memory
    (We would know if you would give us the info about this)

2. The corruption is because EXCEL uses a different Runtime DLL (with strlen)  to that
     your Debug DLL requires. You can check this by using an own string length function like that:

    int stringLength(const char* psz)
         int i = 0;
         while(psz[i] != '\0') i++;
         return i;

Regards, Alex


OK, here we go for the results using quick watch:

func[nFuncs][i]                       0x03c03fd0       " ThisCell"
                                             32  '  '

func[nFuncs][i] + 1                 0x03c03fd1        "ThisCell"  // pls note no space in front
                                             84  'T'

(char*)(func[nFuncs][i] + 1)    0x03c03fd1        "ThisCell"
                                             84  'T'

nFuncs                                   0

i                                            0

I have tried using proposed own stringlength function under 2. above but it still gives me the access violation message.


And since I am at it, here's the quick watch for (BYTE) strlen(func[nFuncs][i]+1):

(BYTE) strlen(func[nFuncs][i]+1)            CXX0019: Error: bad type cast


It's normal, BYTE is a #define and can't quickwatch it. And neither function call results

>I have tried using proposed own stringlength function under 2. above but it still gives me the access violation message.
What is the value of i when the exception is thrown?
>> I have tried using proposed own stringlength function under 2. above but it still
      gives me the access violation message.

That looks like EXCEL isn't using your new DLL but an elder version still using strlen. You should try to debug to new stringLength function and tell the statement where it crashes.

>> What is the value of i when the exception is thrown?
>> 9

??? if i == 9,  the variable i is corrupted and func[nFunc][i]+1 most likely is corrupted also. That might imply that you cannot use Debug DLL with Excel.

Regards, Alex


Regarding 2. I have tried to debug using the "home-made" stringlength function but get exactly the same error message.

Otherwise the exception is thrown the first time around the loop, when i = 0.

not sure what to try next...
>> I have tried to debug using the "home-made" stringlength function

Could you jump into the new function? What is the last statement you can step to? Can you set a breakpoint before you call new stringLength() or did you enter the Debugger only after crash?

Is it a multi-threaded or single-threaded DLL? (Check Settings - C++ - Code Generation )
Is Release DLL working? And if yes, why do you need to run it with Debug DLL? What version of EXCEL do you use? What is the Windows version?

The last questions are because there are some MS Office Versions that (have to) use a special version of mfc42.dll, what may cause conflicts if the DLL is using a different mfc42d.dll. Also a mix of single-threaded and multi-threaded may cause problemes. I would assume that Excel is using multi-threaded runtime dlls, so you should have a multi-threaded dll also.

Regards, Alex


I can jump into the stringLength function and it returns 8.
So it seems to be working no problem.
It seems to be crashing when trying to cast the result to (BYTE).
I know you do not like the disassembly window, but it crashes on the last line:

523:               func[nFuncs][i][0] =  (BYTE) stringLength(func[nFuncs][i]+1);
03E91540   mov         eax,[nFuncs (03fd13a8)]
03E91545   imul        eax,eax,4Ch
03E91548   mov         ecx,dword ptr [ebp-4]
03E9154B   mov         edx,dword ptr [eax+ecx*4+3FC7028h]
03E91552   add         edx,1
03E91555   push        edx
03E91556   call        @ILT+280(stringLength) (03e9111d)
03E9155B   add         esp,4
03E9155E   mov         ecx,dword ptr [nFuncs (03fd13a8)]
03E91564   imul        ecx,ecx,4Ch
03E91567   mov         edx,dword ptr [ebp-4]
03E9156A   mov         ecx,dword ptr [ecx+edx*4+3FC7028h]
03E91571   mov         byte ptr [ecx],al

I entered the debugger before crashing by setting a breakpoint before stepping into the trouble line.

I checked the settings and they are currently as "Debug Multithreaded". Not sure what that means though.

The Release DLL is working beautifully without a single hitch.
I want to run the Debug DLL in order to step through my new code and debug it.

I use Excel 2002 SP-2.
The windows version is XP Professional version 2002, Service Pack 1.



Looks like I solved the problem.

I went into my workspace settings and set my debug info to "Program Database" from "Program Database Edit & Continue".

I am not sure why but now it works without crashing on the usual line now.

Alex, Thanks for spending so much time on this problem.
I am going to give you the points.
If anybody has any idea as to why this option makes the difference, I would be very interested in knowing why.

Unlock this solution and get a sample of our free trial.
(No credit card required)


Ok Thx.
Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a sample view!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.