Microsoft office PDB files. RRS feed

  • Question

  • Hello,

    My company develops an extension to Microsoft Excel. From macro in VBA a COM Library (VB6) is executed.

    The solution worked for years, but suddenly we experience a random Excel.exe crash on Windows Server 2008. The crash exception code is 5 -> Access Violation.

    I tried making a crash dump but i can't read anything from it apart from the fact that some code in Excel.exe module is trying to read memory under address 0x00000002.

    I am able to attach a Visual Studio to Excel.exe and stop on Access Violation. However I can't read stack since there is no PDB for Excel.exe

    I have following modules on the stack:






    Is it possible to get a stripped PDB's for them so that I can actually see my code on the call stack?


    Wednesday, February 1, 2012 1:37 PM

All replies

  • Visual Studio can download symbol files from the Microsoft Server on demand.

    Tools -> Options -> Debugging -> Symbols in MS Visual Studio 2010.

    Jose R. MCP
    Wednesday, February 1, 2012 1:44 PM
  • I'm using MS Visual Studio 2008 and clicking option "Load Symblols From -> Microsoft Symbol Server" is not working.

    I have set up the symbol path to, but the symbols for office aren't there.

    Wednesday, February 1, 2012 2:03 PM
  • I also checked on Visual Studio 2010, and the symbols are not loaded for these DLLs. It looks like there are no PDB files on Microsoft Symbol Server for these.



    Monday, February 6, 2012 9:32 AM
  • I'm not sure that the excel pdb's would help you that much even if you could get them.

    From your description it sounds to me like you have some kind of COM rule violation going on that some change in OS/Excel has uncovered.

    Possibilties are
    1) Incorrect addref/releasing
    2) Incorrect variant handling
    3) calling excel using COM from another thread.

    Can you describe what the COM libary does?  What's the signiture if the function?  Do you create threads?  Are there callbacks to VBA?

    One other line of investigation in this sort of case can bee to look at the assembler around the crash site and see if you can work out from the registers what memory location the 0x0000002 is coming from and the looking there to see what kind of object it is and if comes from your class.  Also if you can reproduce the issue does it also occur with the debug build of your component.


    Monday, February 6, 2012 9:49 AM
  • Thanks for answer.


    COM component is written in VB6, which is interpreted language, that has COM nicely wrapped up and invisible. So:

    1) There is no addref/release called explicitly from VB6 code. There is no such possibility I guess.

    2) Everything is done by VB6 automatically...

    3) There are no threads in VB6, this is single threaded app.


    I guess that the access violation happens when excel is trying to access the collection of worksheets or workbooks. But this is my guess from looking at Dissasembly and general observation and it might not be correct. The PDBs would help me investigate, where am I in my code, when the crash occurs. I would then know, what method of excel I have called. Then I could see if this is the same method at every crash or not. Maybe then I would be able to make some workaround and use different methods in this place? 

    There is no release/debug builds in VB6. We have an option to compile to P-Code or to Native and turn on and off optimalizations. As far as we can observe it crashes on every possible compilation.

    What the COM component does:

    It displays a modal dialog (launched from VBA by pressing a button). It opens some workbooks. Then it in the loop performs some actions on these workbooks (like reading data from it, executing calculate, and so on.) Then it saves the workbooks periodically. The crash occurs after random period of time (from 10mins to 1 day). The same application on windows XP, works fine.

    Monday, February 6, 2012 10:37 AM
  • Ahh VB6, it's been a while :)

    How does the periodic saving work, is this using a timer control, I'd have a concern about this potentially being on a different thread to the main excel calculation thread. Is the crash at/soon after the time an automatic save occurs?


    Monday, February 6, 2012 11:06 AM
  • Periodic saving works like that:


    In the button click event handler (button is on modal dialog) there is a loop. In the loop there are "DoEvents". There is no timer and no threads. (Well, there are timers and there are callbacks from excel, since the code is rather large, but the timers are not related to saving the workbooks).

    Anyway, the saving is optional feature, and with saving disabled, the loop crashes anyway.

    The exact crash place is hard to track due to missing PDB's and random nature of crash. (During debugging -> no crash).

    So the only way I know of where I could see the place in code where the crash occurs is to attach to Process with newer visual studio, compile VB6 to native with PDB, and then configure VS Exceptions to stop on Access Violation, then watch the stack trace. However the access violation is in Excel.exe module and since there is no PDB, the rest of stack trace is not accurate and shows garbage.

    • Edited by Releesha Monday, February 6, 2012 12:22 PM
    Monday, February 6, 2012 12:18 PM
  • Hmmm, does sound like a hard one to get to the bottom of. Even without a pdb the call stack should not be garbage, it can get to be garbage if you have a corrupted stack which can happen if the get past a recursion limit.

    The approach I'd use next would be to enable logging in all the important parts of the code and find what's being called, has been called just before a crash.  Worst case just use MsgBox as logging then gradually isolate the problem code. Better to use OutputDebugString and DebugView if you don't have a handy logging framework


    Monday, February 6, 2012 1:48 PM
  • Well, the callstack, seems to be ok, until I load PDB for windows libraries on the stack. Then I start having callstack starting from something like 0x64Fa83bb. Without the module name. This leads me to conclusion that I can't rely on the callstack.


    The logging is enabled. However, this lead us to nowhere. If we enable detailed logging -> we no longer experience a crash (excel slows down much).

    With standard logging, the final trace we get, led us nowhere:













    The problem might be in our "Tracing" code, since this component updates GUI (traces are also shown on GUI) and probably does another DoEvents, which in turn can launch some timers, or callbacks, which in turn call excel method that crashes? This is why the call stack would be really helpful... 

    We are currently without any ideas on how to investigate the issue and it is critical blocker for our customer :/

    Monday, February 6, 2012 2:02 PM
  • If you're running VBA or VB6 then there will be some machine generated code that won't be in any module in the stack that will look that that.

    Issues where the insertion of logging or other methods to force serialization of calls change behaviour usually point to a threading or call-back issue.  I'd be concerned about the doevents allowing multiple simultanious calls into your code, make sure you log the threadid will all the logging calls and if possible the entry and exit at each entry point.

    Have you tried adding code like

    If alreadyDoingSomething = true then

    Exit sub

    end if

     alreadyDoingSomething = true

    do Stuff

     alreadyDoingSomething = false

    around all the entry points, I vaguely remember having to do this a while ago


    Monday, February 6, 2012 2:11 PM
  • Thank you for suggestions, I will try that.


    However, I would see even with our simple logging that some function is being called twice.

    This can't be threading issue since all Windows callbacks are done in the same thread. The threads are not explicitly created by us. This means the only situation where our code is executed by 2 threads is when excel runs another VBA routine simultanously in different thread. I think this would be a severe bug in MS Office and excel is not doing that.

    The thread ID on which the access violation occurs is always the same: main excel thread.


    What you told about machine generated code -> hmm.. this means that the problem starts in VBA. Since that was what I got at the bottom of the stack trace. So the callback might be the problem. Also I believe we don't have any logging in VBA code. We will try following this path.

    Monday, February 6, 2012 2:46 PM