locked
Missing file was in %CSIDL_SYSTEM% RRS feed

  • Question

  • Hi,

    We have sequencing an application when we run the app it say that it is missing a fil in system32. When I add the missing file (msvcp71.dll) to system32 the application run fine. Simple I thought I update the App-V package with the missing fil in system32.

    But when I open the package it have %CSIDL_SYSTEM%\msvcp71.dll there, so why cant it use that one, and need an file on the local system32.

    /SaiTech


    /SaiTech
    • Edited by SaiTech Tuesday, June 26, 2012 4:21 PM
    Monday, October 3, 2011 5:19 PM

Answers

All replies

  • Are you running the package in 64-bit Windows?

     


    br,
    Kalle Saunamäki
    http://blog.gridmetric.com/
    Monday, October 3, 2011 6:11 PM
    Moderator
  • Use Process Monitor to monitor the execution of the package and determine where the application is looking for msvcp71.dll at runtime.

    This forum post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.
    Monday, October 3, 2011 6:25 PM
    Moderator
  • It's kind of the easier theory but like what I think Kalle is going to suggest. Is it running on 64-bit? If so you may need to think about SysWOW.

     

    It might need a 64-bit and 32-bit version of the distributable. Assuming as that's what the dll looks like to me.

    Tuesday, October 4, 2011 10:00 AM
  • You're right, if it's running on 64-bit then %CSIDL_SYSTEM% will be mapped to c:\Windows\Syswow64 and not c:\Windows\System32, which could explain the issue. For more pointers, please see my recent post on the matter of mixing bitnesses: http://blog.gridmetric.com/2011/09/26/possible-caveats-in-mixing-32-bit-and-64-bit-app-v-packages-and-environments/

    If it's not 64-bit Windows then another possible suspect would be SxS and/or if there are multiple copies of msvcp71.dll in all the different places. One thing to try out is to put msvcp71.dll into same directory where the main executable is [in the package].

     

     


    br,
    Kalle Saunamäki
    http://blog.gridmetric.com/
    Tuesday, October 4, 2011 10:06 AM
    Moderator
  • Resurrecting an old thread, but the answers above contradict the documentation:

    1. CSIDL_SYSTEM (like all the other CSIDL values) is a constant, not an environment variable, therefore %CSIDL_SYSTEM% doesn't make sense to me.

    2. I just tried calling SHGetFolderPath with CSIDL_SYSTEM from a 32-bit application on a 64-bit system and it returns C:\Windows\System32, not SysWOW64. The documentation (for VS2010) says you have to call explicitly with CSIDL_SYSTEMX86 to get SysWOW64.

      It seems all wrong to me - CSIDL_SYSTEM should translate to the correct folder for whatever system - but that's what actually happens.

    (I hope someone is still monitoring this thread.)

    Edit: I don't know why the heading is showing 0 Points! (Ah - I was confusing this with StackOverflow :) )



    Monday, June 25, 2012 10:44 AM
  • Resurrecting an old thread, but the answers above contradict the documentation:

    1. CSIDL_SYSTEM (like all the other CSIDL values) is a constant, not an environment variable, therefore %CSIDL_SYSTEM% doesn't make sense to me.

    2. I just tried calling SHGetFolderPath with CSIDL_SYSTEM from a 32-bit application on a 64-bit system and it returns C:\Windows\System32, not SysWOW64. The documentation (for VS2010) says you have to call explicitly with CSIDL_SYSTEMX86 to get SysWOW64.

      It seems all wrong to me - CSIDL_SYSTEM should translate to the correct folder for whatever system - but that's what actually happens.

    (I hope someone is still monitoring this thread.)

    Edit: I don't know why the heading is showing 0 Points!

    Sure it's a constant in general Windows programming (actually also superseded by KNOWNFOLDERID_ constants since Vista), but in context of App-V those values behave little bit differently. Back in the day, App-V took these well-known constants and added few of its own (SFT_SID etc.), and made them variables inside App-V; i.e. they are not the "same" CSIDL values as programmers know them in Win32 API but merely happens to share the same name as well as resolve pretty much to the same path values.

    Now, when App-V introduced 64-bit support in 4.6, they kept the variables as is in 32-bit world to enable package portability (running old App-V packages in 64-bit systems) and introduced additional variables for distinguishing 64-bit world. You can see some of them in the blog posting I referred to in my earlier post (including that SFT_SYSTEM32_X64 which is what "normal" CSIDL_SYSTEM resolves to in Windows).

    Hope this makes sense?

    br,
    Kalle


    Monday, June 25, 2012 10:59 AM
    Moderator
  • Thanks for the quick response! My apologies - I did not notice this was specific to App-V (which I confess I did not know about!) when I came here from Googling stuff.

    Yes, I know about KNOWNFOLDERID and that SHGetFolderPath is deprecated, but I need to continue supporting my XP users at the moment (will they ever go away??).

    So you're saying that in your software CSIDL_SYSTEM translates to System32 or SysWOW64 depending on bit-ness? Wish you would tell the Windows people about that!! (The current way is illogical, though I can check in other ways which constant I need.)

    Monday, June 25, 2012 11:46 AM
  • App-V is not my software, it's Microsoft's ;-)

    But yes, CSIDL_SYSTEM in App-V always refers to 32-bit System32 directory whereas SFT_SYSTEM32_X64 refers to same under 32-bit system (as there's no distinction) and 64-bit version under 64-bit system.


    br,
    Kalle Saunamäki
    http://blog.gridmetric.com/

    Monday, June 25, 2012 11:52 AM
    Moderator