Microsoft Visual C++ Runtime Library Runtime Error

Discussion in 'Windows Server' started by Ron Sochanski, Jun 18, 2009.

  1. Hello. I have a 32-bit MFC application that runs fine on Windows Server 2003
    Standard Edition SP2. However, when I try to run it on Windows Server 2003
    R2 Standard x64 Edition SP2, I get the following error message:

    Microsoft Visual C++ Runtime Library
    Runtime Error!
    Program C:\...
    This application has requested the Runtime to terminate it in an unusual
    way. Please contact the application's support team for more information.

    I tried to apply the hotfix described in KB916177, only to find that Windows
    Server 2003 R2 Standard x64 Edition SP2 already contains the fix.

    Any help with fixing this error would be greatly appreciated. Thank you.
     
    Ron Sochanski, Jun 18, 2009
    #1
    1. Advertisements

  2. Dusko Savatovic, Jun 19, 2009
    #2
    1. Advertisements

  3. The application in question is 32-bit and was developed with Visual C++ 6.0.
    Please correct me if I'm wrong, but I don't think that the 64-bit Visual C++
    2008 redistributable would help, since it's for 64-bit Visual C++ 2008
    applications.
     
    Ron Sochanski, Jun 19, 2009
    #3
  4. Try to download Application Compatibility Toolkit. It is designed for Vista,
    but since 2008 is designed on the similar base it may help. ACT contains so
    called 'shims' that can help you set up a 'fake' environment for your app.
    It can also monitor API's used in the app and give you detailed report.

    I suppose you already tried the usual trick with 'Run as Administrator'
    during the app install and launch.
     
    Dusko Savatovic, Jun 19, 2009
    #4
  5. I did not yet try the Application Compatibility Toolkit as you had suggested.
    I did, however, copy the executable from C:\Program Files (x86)\... to
    C:\Program Files\... and then ran the executable from there. The error did
    not occur.
     
    Ron Sochanski, Jun 19, 2009
    #5
  6. Thanks for sharing, Ron

     
    Dusko Savatovic, Jun 19, 2009
    #6
  7. Dusko, any idea as to why the error would occur with the executable installed
    in C:\Program Files (x86) but not when it's installed in C:\Program Files?
    Could I perhaps modify the system path so that the error doesn't occur when
    installing in C:\Program Files (x86)?
     
    Ron Sochanski, Jun 19, 2009
    #7
  8. Ron, that's how it works now and how Microsoft arranged things now with
    64-bit technology. It's better not to mess with system paths. You found a
    good solution so leave it as it is. If you really have to, it would be a
    good idea to do modifications for individual scenarios and by using a batch
    file that would set the necessary environment variables and invoke the
    application. Like I mentioned before, Application Compatibility Toolkit has
    a feature for presenting 'fake' environment to apps, so it's worth
    investigating if you're preparing for some serious migrations. They call
    this 'fake' environment a virtualized environment. What happens is that they
    intercept API calls and if the app wants to write to a restricted location
    (such as %windir%), a similar folder structure is created inside a user's
    profile. Check the Technet site for more info:
    http://technet.microsoft.com/en-us/windows/aa905066.aspx
     
    Dusko Savatovic, Jun 19, 2009
    #8
  9. Dusko, my solution puts a 32-bit executable into the 64-bit \Program Files
    directory, which I thought was reserved for 64-bit programs. Is the
    acceptable?
     
    Ron Sochanski, Jun 19, 2009
    #9
  10. Ron, your case is exception to the rule. It seems that your app is hard
    coded for '\Program Files' instead of %ProgramFiles%. Besides, it was made
    with Visual C++ 6.0. IIRC Visual C++ 6.0 did not create 64-bit apps. So
    there's no danger of mixing 32-bit and 64-bit components of that same name
    ie it's unlikely that another 64-bit app will reference the same component
    (only it's 64-bit version), but get the 32-bit version instead.
     
    Dusko Savatovic, Jun 19, 2009
    #10
  11. Dusko, I'm not sure what you mean by "mixing 32-bit and 64-bit components".
    Could you please explain. Thank you.
     
    Ron Sochanski, Jun 19, 2009
    #11
  12. The biggest strength of C++ is components. For example, when in your program
    you have a File menu and the file dialog opens, this comes from a file
    comdlg32.dll. It's called Common Dialogs. This component is used by almost
    all (Windows based) programs that open/close files. When the application is
    reworked for 64-bits, it is recompiled with minimum change of the source
    files. However 64-bit app will not call comdlg32.dll, but some other 64-bit
    ..dll file. During the time of VC++ 6.0 , there was a period known as "DLL
    Hell". It was because more apps could use the same dll file and one app
    could overwrite the newer dll and replace it with the older version. Also,
    when uninstalled, an app could have removed a dll that other apps might have
    still been using.
    Anyway, this situation is now solved and the chances of running into "DLL
    Hell" are very slim.
     
    Dusko Savatovic, Jun 19, 2009
    #12
  13. Ron Sochanski

    Peter Foldes Guest

    The Google Toolbar is the culprit on this one. Uninstall it and reboot and then
    re-install
     
    Peter Foldes, Jun 19, 2009
    #13
  14. You were right! My app was hard-coded with '\Program Files' instead of
    %ProgramFiles%. I did not realize this. I have modified the app to use
    %ProgramFiles% instead and my problem has been solved. Thanks very much for
    your help and insight.
     
    Ron Sochanski, Jul 2, 2009
    #14
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.