Home/ Questions/Q 296223
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T06:31:44+00:00

We have a native C++ application running via COM+ on a windows 2003 server.

  • 0

We have a native C++ application running via COM+ on a windows 2003 server. I’ve recently noticed from the event viewer that its throwing exceptions, specifically the C0000005 exception, which, according to http://blogs.msdn.com/calvin_hsia/archive/2004/06/30/170344.aspx means that the process is trying to write to memory not within its address space, aka access violation.

The entry in event viewer provides a call stack:

LibFmwk!UTIL_GetDateFromLogByDayDirectory(char const *,class utilCDate &) + 0xa26c
LibFmwk!UTIL_GetDateFromLogByDayDirectory(char const *,class utilCDate &) + 0x8af4
LibFmwk!UTIL_GetDateFromLogByDayDirectory(char const *,class utilCDate &) + 0x13a1
LibFmwk!utilCLogController::GetFLFInfoLevel(void)const + 0x1070
LibFmwk!utilCLogController::GetFLFInfoLevel(void)const + 0x186

Now, I understand that its giving me method names to go look at but I get a feeling that the address at the end of each line (e.g. + 0xa26c) is trying to point me to a specific line or instruction within that method.

So my questions are:

  1. Does anyone know how I might use this address or any other information in a call stack to determine which line within the code its falling over on?
  2. Are there any resources out there that I could read to better understand call stacks,
  3. Are there any freeware/opensource tools that could help in analysing a call stack, perhaps by attaching to a debug symbol file and/or binaries?

Edit:
As requested, here is the method that appears to be causing the problem:

BOOL UTIL_GetDateFromLogByDayDirectory(LPCSTR pszDir, utilCDate& oDate)
{
BOOL bRet = FALSE;

if ((pszDir[0] == '%') &&
    ::isdigit(pszDir[1]) && ::isdigit(pszDir[2]) &&
    ::isdigit(pszDir[3]) && ::isdigit(pszDir[4]) &&
    ::isdigit(pszDir[5]) && ::isdigit(pszDir[6]) &&
    ::isdigit(pszDir[7]) && ::isdigit(pszDir[8]) &&
    !pszDir[9])
{
    char acCopy[9];
    ::memcpy(acCopy, pszDir + 1, 8);
    acCopy[8] = '\0';

    int iDay = ::atoi(&acCopy[6]);
    acCopy[6] = '\0';
    int iMonth = ::atoi(&acCopy[4]);
    acCopy[4] = '\0';
    int iYear = ::atoi(&acCopy[0]);

    oDate.Set(iDay, iMonth, iYear);

    bRet = TRUE;
}

return (bRet);

}

This is code written over 10 years ago by a member of our company who has long since gone, so I don’t presume to know exactly what this is doing but I do know its involved in the process of renaming a log directory from ‘Today’ to the specific date, e.g. %20090329. The array indexing, memcpy and address of operators do make it look rather suspicious.

Another problem we seem to have is that this only happens on the production system, we’ve never been able to reproduce it on our test systems or development systems here, which would allow us to attach a debugger.

Much appreciated!
Andy

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    if you really need to map those addresses to your functions – you’ll need to work with .MAP file and see where those addresses really point to.

    But being in your situation I would rather investigate this problem under debugger (e.g. MSVS debugger or windbg); as alternative (if crash happens at customer’s site) you can generate crash dump and study it locally – it can be done via Windows MiniDumpWriteDump API or SysInternals ProcDump utility (http://download.sysinternals.com/Files/procdump.zip).

    Make sure that all required symbol files are generated and available (also setup microsoft symbol server path so that windows DLLs’ entry points get resolved also).

    IMHO this is just the web site you need: http://www.dumpanalysis.org – which is the best resource to cover all your questions.
    Consider also taking a look at this PDF – http://windbg.info/download/doc/pdf/WinDbg_A_to_Z_color.pdf

    • 0