none
Access violation in OLE32.dll trying to debug DLL in VS 6.0 SP5 on Win8 x86

    Question

  • I'm trying to run VS 6.0 (SP5) on a Win8 x86 machine. I'm able to debug the main executable just fine (although I needed to install an off-brand copy of TLLOC.DLL written by a gentleman named Dr.Hoiby to be able to rebuild the exe after doing a "stop debugging").

    But, when I halt in one of the DLLs that's part of my project, I can't resume or step without getting an access violation in OLE32.DLL. For reasons that are too complicated to go into, I really must make VS 6 work in this environment. SP6 does not solve the problem.

    Does anyone have a suggestion about how to resolve this problem?

    Tuesday, January 08, 2013 2:15 PM

All replies

  • Hi Walter,

    Thank you for posting in the MSDN forum.

    Maybe you could share us the detailed error message if you got.

    Based on your description, do you mean that you are debugging the dll? If so, maybe you could get the detailed steps from the following MSDN document:

    Debugging DLLs

    In addition, this document shared us some suggestions to debug an Access Violation. For example, we could use the Call Stack window or set the breakpoint to check this issue.

    Best Regards,


    Jack Zhai [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thursday, January 10, 2013 3:39 AM
  • One scenario is when I set a breakpoint in a DLL that is part of a multi-project workspace, after the app is running and the DLL is loaded. Some of the time (and I haven't been able to characterize the circumstances) attempting to step (F10) or go (F5) causes the problem.

    I wasn't able to reproduce this in a couple of tries with a minimal test program (WinMain calling exported function in DLL that had just the one function). My real app has about a dozen DLLs compiled from roughly 300,000 lines of C++ code. Somewhere in between these two extremes is a minimal test case.

    Here are some more details about the symptom. If I set a breakpoint within one of the DLLs, it trips as expected. If I open the disassembly window, I'm able to step the instructions. If I then move the cursor to the source window and try to step a statement, I get a standard MessageBox advising me of an access violation within OLE32.DLL. At this point, all the 32-bit registers (most especially including EIP) are unchanged from what they were before the F10 key, but the disassembly window is now pointed to 76255BC7 (always the same address), which is data belonging to OLE32. Three DWORDS beginning at ESP have been set to zero. Even if I switch to the disassembly window and force it to display my code (say by dragging and dropping the EIP register value onto it), every F5 or F10 from now on generates the same symptom.

    BTW, I'm running VS 6.0 SP5 on a clean install right now. (I.e., I completely emptied the Microsoft Visual Studio directory before installing.) I had the same problem with SP6. Just in case it makes a difference, this is running under 6.2.9200 on a Pentium G645 (x64) with 4 GB of memory.

    • Edited by Walter Oney Thursday, January 10, 2013 11:50 AM
    Thursday, January 10, 2013 11:41 AM
  • Hi Walter,

    Glad to receive your reply.

    Maybe I still not very sure about this issue since I couldn’t repro this issue, but if it has the same issue in other machine, I’m afraid that it will be related to this specific app, since this forum is to discuss the VS debugger tool, So I might not have the correct detailed answer you need, but I might lead you into the right direction to solve your problem.

    You would debug it in your side, for example, we could debug an app one step by one step, if we could make sure that which line code generated this issue.  You would discuss the result you got with your development team, or you could post this issue to the development forum, I think you would get better support.

    If possible, you could also share me your project, please also attach your Visual Studio project, you can upload it to the sky drive, and then share the download link in your post. Please share us the detailed steps and which tools I will be install in a machine and the detailed error message, maybe you could share us a screen shot about the result, and then I will try to check it in my machine. If this issue is urgent, please contact support at http://support.microsoft.com.

    If there's any concern, please feel free to let me know.

    Have a nice weekend,


    Jack Zhai [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, January 11, 2013 6:14 AM
  • I've been able to reproduce the problem fairly simply. Bracketed instructions are in case some of the steps aren't clear.

    Create and build a VS add-in DLL that implements a command and does not handle VS events. [Use File/New and select the VS add-in wizard, etc. Build it. Run regsvr32 on it.]

    In the add-in's project settings debug tab, set the executable to msdev [e.g., c:\Program Files (x86)\Microsoft Visual Studio\Common\msdev98\bin\msdev.exe].

    Set a breakpoint at the entry to the command processor the wizard will have created [this will be in Commands.cpp]

    Run the add-in [F5 key]

    When the breakpoint trips, first switch to the disassembly window [Alt+8] and try single-stepping the instructions. This worked for me.

    Switch focus to the source window and try single stepping there [F10]. This generated the access violation for me.

    Friday, January 11, 2013 11:12 AM
  • Hi Walter,

    Sorry for my delay.

    Since just the specific dll file has this issue, I’m afraid these questions require a more in-depth level of support.

    Since the Microsoft Connect feedback portal (http://connect.microsoft.com) just supported the latest VS version VS2012, so if you have it, you could try to debug the dll file in the latest VS version like this. If it still has this issue, you could create connect report for it. You will get email notification for update.http://connect.microsoft.com/VisualStudio/feedback/CreateFeedback.aspx

    If possible, you could visit this link to see the various support options that are available to better meet your needs:

    http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone. Thanks for your understanding.

    Sincerely,


    Jack Zhai [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Tuesday, January 15, 2013 3:29 AM
  • I posted details about how to easily reproduce my problem, but I think the forum software did not recognize it as a reply to your latest reply. Solving this problem in the context of VS 6 is very important to me, so I hope someone on this forum can proactively forward it to wherever it needs to go.
    Tuesday, January 15, 2013 2:24 PM
  • Hi. I have the same problem. Installing visual studio 6 + sp6 on windows 8 was a real headache but I managed to do it. My problem now is an access violation at ole32.dll while debugging. To produce the problem is very easy. Produce a dialog based mfc application. You can debug it without any problems. But if you put an activex control on the dialog like msflexgrid, and after you debug the application you get the access violation at ole32.dll. I hope someone finds a solution to this problem.
    Tuesday, January 29, 2013 7:49 AM
  • I found a workaround that I posted in a different Microsoft forum. Just make sure there is a breakpoint in your program before OLE32.DLL gets loaded into the process. Step over that breakpoint and "go". From then on, you can debug the program normally.

    I actually wrote a header file that I now include very early in all my projects, e.g.:

    X64DebugHack.h:

    #ifdef _DEBUG
     // In order to be able to debug this application on x64, we need to single
     // step across at least one statement before ole32.dll gets loaded. So
     // always leave this breakpoint in place.

    requiredbreakpoint:
     int junkola = 42;

     // Check to see that there was a breakpoint...

     PUCHAR pjunk;
     _asm lea eax, requiredbreakpoint
     _asm mov pjunk, eax

     if (*pjunk != 0xCC)
      AfxMessageBox("Required breakpoint was not set prior to loading OLE32.DLL -- single stepping will not be possible during this debugging session.", MB_OK | MB_ICONHAND, 0);

     LoadLibrary("OLE32");
    #endif

    BOOL CMyApp::InitInstance()
     {  
    #ifdef _AFXDLL
     Enable3dControls();   // Call this when using MFC in a shared DLL
    #else
     Enable3dControlsStatic(); // Call this when linking to MFC statically
    #endif

     #include <X64DebugHack.h>

    [etc.]

    Tuesday, January 29, 2013 8:56 AM
  • For the dialog based application, I did what you suggested. I put a breakpoint at the constructor of the application. It worked like magic. But for applications using dlls, wherever I put the breakpoint I was unsuccessful. I even put a breakpoint at CRTEXE.C file. It does not help. Do you know the first C or CPP file that is being loaded?

    Actually, F10(Step Over), and F11(Step Into) are causing this problem. If you set another breakpoint at next line and press F5 there is no problem. Or you can use Ctrl+F10(Run to Cursor). Strange. I hope Microsoft prepares a hotfix for this problem.

    Tuesday, January 29, 2013 9:48 AM
  • I have the same problem the minimum reproduction is dialog whith  one ActiveX control when i try using Step Over or Step Into I have mentioned acces  violation. I have Windows 8 64 bit.

    Have somebody found any information according this issue?

    Wednesday, February 20, 2013 10:34 AM
  • I am also having the same issue as everyone else here.  Win 8, 64 bit machine.  Anyone figure out a solution?
    Monday, February 25, 2013 2:31 PM
  • I am running VC++ 6.0 SP6 on Windows 8, 64-bit, so my experience may not directly relate to Walter Oney's problem.  I had a very similar problem, in that single stepping anywhere in my programs caused an access violation in OLE32.dll.  I didn't know how to go about implementing Walter Oney's hack. 

    I eventually solved the problem by unchecking "OLE RPC Debugging" on the Tools/Options.../Debug dialog box tab.  My code is just plain Win32 & C, and I'm not making any direct use of OLE32.dll.  My fix probably won't help if you actually need OLE RPC debugging.

    Monday, April 01, 2013 8:19 PM
  • I had the same error "Access violation in OLE32.dll", using VS 6 in Win8 64 bits, i uncheck OLE RPC debugging and works great. Thanks.

    Just a comment: I need to check "just-in-time debugging" prior to uncheck "OLE RPC debugging".

    I try to make a test program but dont work, only in my program raizes the error.

    Monday, June 10, 2013 3:58 PM
  • Works for me too, thank you very much for the tip.

    I don't know how long we're going to keep vs6 running, but we're ok before windows 9 at least!

    Tuesday, September 10, 2013 3:21 PM