locked
First-chance exception with tabs RRS feed

  • Question

  • Hi there,

     

    I have a dialog control using property sheet and pages. I just noticed that there is always a "first-chance exception" when the first time I clicked a different tab. It looks like this:

     

    First-chance exception at 0x5d0c3216 in MyTest.exe: 0xC0000005: Access violation writing location 0x004350f4.

     

    When I search for some help this came up:

     

    Note   The first time a property page is created from its corresponding dialog resource, it may cause a first-chance exception. This is a result of the property page changing the style of the dialog resource to the required style prior to creating the page. Because resources are generally read-only, this causes an exception. The exception is handled by the system, and a copy of the modified resource is made automatically by the system. The first-chance exception can thus be ignored.

     

    Is this saying the exception I am getting? Or there is a bug in my code caused my exception?

     

    Thanks a lot!!

    Tuesday, March 25, 2008 5:49 PM

Answers

  • You can tell the debugger to break on first-chance exceptions. Along with unwind information in the public symbols available via symbol server you should get an idea what's going on. IIRC the thing you mentioned above happens in the EditTemplate function. Looking at the address it sounds unlikely though.

     

    Anyway, make sure you enable breaks on first chance exceptions (it's in Debug->Exceptions->Win32 Exceptions->Break when thrown, break on first chance or something similar -- I think this has changed in pretty much every revision of the IDE). VS 2005+ has builtin support for symbol server for prior versions there are some KB articles on how to set it up.

     

    -hg

    Tuesday, March 25, 2008 7:45 PM
  • First thing I'd do is take a look at the callstack (again make sure you have symbol server set up -- it may take a while to download symbols but you won't want to miss the information you get)

     

    What follows next is just identifying the exact error. The best way would be to take a look at the machine code to find the offending instruction (it should be marked already when you got to disassembly -- however the exception output also includes the code address)

     

    I don't really see how this could fail with the provided exception message. Anyway, from the exception message it sounds like the error occurs inside MFCxx.dll while trying to access memory in your EXE (that's just a guess based on the addresses)

     

    Can you show us the disassembly and the callstack?

     

    -hg

     

    Wednesday, March 26, 2008 9:44 AM
  • The debugger tricks you here. You are not at the top of the callstack. The instruction you highlighted is only the one that would be executed once all active functions have returned.

     

    But you still don't have public symbols for the Microsoft DLLs which means you the debugger has to guess to reconstruct the callstack. In fact, I'm fairly certain the callstack is completely bogus in this case.

     

    Make sure you have symbols:

    http://msdn2.microsoft.com/en-us/library/b8ttk8zy(VS.71).aspx

     

    and take a look at the disassembly on the top of the callstack (if the debugger tells you there's no source code insist on the disassembly :-) )

     

    -hg

    Wednesday, March 26, 2008 7:10 PM
  • You will need the instruction for Microsoft public symbol server.

     

    In your case, there is a problem somewhere in a Microsoft DLL. Now the debugger is trying to reconstruct how the program ended up there. To do so it uses a virtual table in the debug information that is indexed by the program location and hold information how to unwind the stack to the caller function. This is repeated till there is no more caller.

     

    Hence, you need the Microsoft PDBs. Microsoft store all Windows DLLs & PDBs on this server. So if you have a patched machine you'll still get symbol information.

     

    For your DLLs/EXEs you will usually have symbols on your machine (the DLL or EXEs have the full path to the PDB in their debug header). THe debugger will automatically check this location for you.

     

    -hg

    Wednesday, March 26, 2008 11:36 PM

All replies

  • You can tell the debugger to break on first-chance exceptions. Along with unwind information in the public symbols available via symbol server you should get an idea what's going on. IIRC the thing you mentioned above happens in the EditTemplate function. Looking at the address it sounds unlikely though.

     

    Anyway, make sure you enable breaks on first chance exceptions (it's in Debug->Exceptions->Win32 Exceptions->Break when thrown, break on first chance or something similar -- I think this has changed in pretty much every revision of the IDE). VS 2005+ has builtin support for symbol server for prior versions there are some KB articles on how to set it up.

     

    -hg

    Tuesday, March 25, 2008 7:45 PM
  •  

    Thanks for the kind response.

     

    Actually, I later noticed I missed one exception: There is another one before the dialog pops up:

     

    First-chance exception at 0x5d0c3216 in MyTest.exe: 0xC0000005: Access violation writing location 0x00434b64.

     

    I set break into the program as you suggested. At both times (before the dialog pops up or after I clicked a different tab once it starts up), the program breaks into wincore.cpp at:

     

     

    void AFXAPI AfxHookWindowCreate(CWnd* pWnd)

    {

    _AFX_THREAD_STATE* pThreadState = _afxThreadState.GetData();

    ....

     

     

    What does this mean?

     

    Thanks a lot.

     

     

     

    Tuesday, March 25, 2008 10:29 PM
  • First-chance exceptions are usually normal. If that is the only indication of a problem and if everything else is working then just ignore First-chance exceptions.

     

    Sometimes it is easier for Microsoft to allow First-chance exceptions to occur and then the runtime code deals with the event. It is often a relatively normal occurance happening.

    Wednesday, March 26, 2008 6:52 AM
  • First thing I'd do is take a look at the callstack (again make sure you have symbol server set up -- it may take a while to download symbols but you won't want to miss the information you get)

     

    What follows next is just identifying the exact error. The best way would be to take a look at the machine code to find the offending instruction (it should be marked already when you got to disassembly -- however the exception output also includes the code address)

     

    I don't really see how this could fail with the provided exception message. Anyway, from the exception message it sounds like the error occurs inside MFCxx.dll while trying to access memory in your EXE (that's just a guess based on the addresses)

     

    Can you show us the disassembly and the callstack?

     

    -hg

     

    Wednesday, March 26, 2008 9:44 AM
  • Here is the disassembly:

     

    void AFXAPI AfxHookWindowCreate(CWnd* pWnd)

    {

    7C3403A0 push ebp

    7C3403A1 mov ebp,esp

    7C3403A3 push ecx

    _AFX_THREAD_STATE* pThreadState = _afxThreadState.GetData();

    7C3403A4 mov ecx,offset _afxThreadState (7C43CED0h)

    7C3403A9 call CThreadLocal<_AFX_THREAD_STATE>::GetData (7C3B04C0h)

    7C3403AE mov dword ptr [pThreadState],eax <=== break point

    if (pThreadState->m_pWndInit == pWnd)

    7C3403B1 mov eax,dword ptr [pThreadState]

    7C3403B4 mov ecx,dword ptr [eax+14h]

    7C3403B7 cmp ecx,dword ptr [pWnd]

    7C3403BA jne AfxHookWindowCreate+21h (7C3403C1h)

    return;

    7C3403BC jmp AfxHookWindowCreate+0CEh (7C34046Eh)

     

     

    The callstack:

     

      comctl32.dll!5d0c3216()  
      user32.dll!77d4d4de()  
    > mfc71ud.dll!AfxHookWindowCreate(CWnd * pWnd=0x00434b58)  Line 613 + 0xa C++
      comctl32.dll!5d0c352d()  
      user32.dll!77d4d4de()  
      comctl32.dll!5d0c3618()  
      comctl32.dll!5d0c597f()  
      comctl32.dll!5d0be066()  
      user32.dll!77d48709()  
      user32.dll!77d487eb()  

    Thanks for your effort on my question!

    Wednesday, March 26, 2008 5:44 PM
  • The debugger tricks you here. You are not at the top of the callstack. The instruction you highlighted is only the one that would be executed once all active functions have returned.

     

    But you still don't have public symbols for the Microsoft DLLs which means you the debugger has to guess to reconstruct the callstack. In fact, I'm fairly certain the callstack is completely bogus in this case.

     

    Make sure you have symbols:

    http://msdn2.microsoft.com/en-us/library/b8ttk8zy(VS.71).aspx

     

    and take a look at the disassembly on the top of the callstack (if the debugger tells you there's no source code insist on the disassembly :-) )

     

    -hg

    Wednesday, March 26, 2008 7:10 PM
  •  

    Hi, I followed the instructions on the page you provided (used local symbol server) and tried again, there is no difference in the disassembly or call statck. I checked my local symbols directory, there are some .pdb files which I assume contain the symbols information.

     

    Any thought?

    Wednesday, March 26, 2008 9:16 PM
  • You will need the instruction for Microsoft public symbol server.

     

    In your case, there is a problem somewhere in a Microsoft DLL. Now the debugger is trying to reconstruct how the program ended up there. To do so it uses a virtual table in the debug information that is indexed by the program location and hold information how to unwind the stack to the caller function. This is repeated till there is no more caller.

     

    Hence, you need the Microsoft PDBs. Microsoft store all Windows DLLs & PDBs on this server. So if you have a patched machine you'll still get symbol information.

     

    For your DLLs/EXEs you will usually have symbols on your machine (the DLL or EXEs have the full path to the PDB in their debug header). THe debugger will automatically check this location for you.

     

    -hg

    Wednesday, March 26, 2008 11:36 PM
  •  

    I just noticed that I made a mistake... Actually there are two First-chance exceptions occuring in my application. First time it happens before the dialog pops up, which has the disassembly and call stack information as I posted. Second time it happens when I click on a different tab, its disassembly and call stack are as follows:

     

     

    void AFXAPI AfxHookWindowCreate(CWnd* pWnd)

    {

    7C3403A0 push ebp

    7C3403A1 mov ebp,esp

    7C3403A3 push ecx

    _AFX_THREAD_STATE* pThreadState = _afxThreadState.GetData();

    7C3403A4 mov ecx,offset _afxThreadState (7C43CED0h)

    7C3403A9 call CThreadLocal<_AFX_THREAD_STATE>::GetData (7C3B04C0h)

    7C3403AE mov dword ptr [pThreadState],eax    <== break point

    if (pThreadState->m_pWndInit == pWnd)

    7C3403B1 mov eax,dword ptr [pThreadState]

    7C3403B4 mov ecx,dword ptr [eax+14h]

    7C3403B7 cmp ecx,dword ptr [pWnd]

    7C3403BA jne AfxHookWindowCreate+21h (7C3403C1h)

     

      comctl32.dll!5d0c3216()  
      user32.dll!77d4d4de()  
    > mfc71ud.dll!AfxHookWindowCreate(CWnd * pWnd=0x004350e8)  Line 613 + 0xa C++
      comctl32.dll!5d0c352d()  
      user32.dll!77d4d4de()  
      comctl32.dll!5d0c3618()  
      comctl32.dll!5d0c597f()  

     

    I tried both the microsoft or my local symbols server, the results are the same.

    Thursday, March 27, 2008 5:34 PM
  • Thanks for responding. Yes, the exceptions seem to be the only problem with my application. Otherwise it runs fine. I just wonder if the exceptions are the one mentioned in MSDN notes as I put in the initial post. If not, what caused them.

     

     

     Simple Samples wrote:

    First-chance exceptions are usually normal. If that is the only indication of a problem and if everything else is working then just ignore First-chance exceptions.

     

    Sometimes it is easier for Microsoft to allow First-chance exceptions to occur and then the runtime code deals with the event. It is often a relatively normal occurance happening.

    Thursday, March 27, 2008 8:28 PM