[C++] VisualStudio 2005/2008 redistribution and manifests problem

Discussion in 'Game Development (Technical)' started by TheMysteriousStranger, Sep 16, 2009.

  1. TheMysteriousStranger

    Original Member

    Joined:
    Jan 17, 2006
    Messages:
    222
    Likes Received:
    0
    I figure someone here must have run into this problem before now...

    I'm trying to test my game on a machine that doesn't have the latest updates and runtime redistributables, etc. I figure this will be a good test for your average user's machine. The problem is that the game refuses to run on another system quoting the ever useful message:

    "The application cannot start because it is configured incorrectly. Reinstalling it might help"

    After some digging, this appears to be a issue around the C++ manifests and side-by-side system which affects only VS2005 and up. The exe needs certain dlls to run (namely the C++ run-time dlls) and a manifest inside the exe is telling windows which ones to use. Unfortunately, these aren't available on the test computer. because it's a typical user who doesn't keep up to date with run time libraries and other stuff they don't understand.

    Another problem is that if I try to compile the exe as a statically linked exe (eg no external dll requirements, all run-times compiled directly into the app), the app crashes, even on the development computer. Which is useful. No error messages, no nothing, just instant crash on startup. I have a feeling this is windows saying "no! bad boy! you will use our stupid manifest system, or else!"

    So I guess my question is, what hoops do I have to jump through to get a native C++ program, developed in VS2008, to run on a typical user's out of date system, without forcing them to download and update various runtimes and installs? (because we all know your average user is going to say - sod that, I'm not downloading/installing anything extra just to play a demo)
     
  2. MFS

    MFS New Member

    Joined:
    Feb 28, 2007
    Messages:
    314
    Likes Received:
    0
    I ran into a similar problem and found the solution on a forum post...somewhere. I can't find the original post but I emailed the key points to myself, so hopefully this might help.

    "In recent versions of MSVC, using the DLL version of the runtimes will create a dependency in your application for the runtime redistributable. You'll generally need to install the redistributable if you want your application to run on a computer that doesn't have MSVC installed. Using the static library version will not have that dependency, but may conflict with other libraries that you may use."

    "It might be resolved by using /MT. If the application uses any libraries that also depend on the DLL version of the runtimes, you'll still need it for those libraries."
     
  3. luggage

    Moderator Original Member Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    2,132
    Likes Received:
    0
    Yeah, I think you need to go into your C++ compiler settings and tell it to use the static library rather than the dynamic one.
     
  4. Applewood

    Moderator Original Member Indie Author

    Joined:
    Jul 29, 2004
    Messages:
    3,859
    Likes Received:
    2
    Yep, that's definitely it.

    It defaults to using DLL builds and you want the static lib option. The label itself is confusing because it looks like you want your own app to be a DLL, but it's actually referring to the crt used. In the past, it was static only so no options were presented.
     
  5. TheMysteriousStranger

    Original Member

    Joined:
    Jan 17, 2006
    Messages:
    222
    Likes Received:
    0
    As I said in my OP (I don't blame anyone for skim-reading, I do tend to waffle on) there's a weird bug that is causing any /MT build to crash immediately on startup without so much as a "haha you suck" message. Oddly, if I do a debug build with /MT it works fine, it's only release builds that bomb on start.

    I'd be happy to do a static release, as I only use the CRT runtime anyway (and openMP, for which I would have to include the dll in the installer, but that's no big deal). I just need to get a static release build to actually work! I'll keep banging my head against the /MT switch and fiddling with compile settings in the hope it will one day magically work, but I'm not hopeful.
     
  6. MFS

    MFS New Member

    Joined:
    Feb 28, 2007
    Messages:
    314
    Likes Received:
    0
    Sorry if I didn't make it clear in my original response -- but I was actually pointing out a common problem in this scenario (and one that I had) where one of the third party libs the application uses depends on the DLL version of the runtimes. This can result in things just being totally broken. A common manifestation in this case is the heap allocation breach across DLLs which is not fun to debug.

    If this happens to be the case and you can rebuild the library in question yourself, then problem averted. Often that's not possible, and you have no choice but to require the end user to get the runtime redistributable.

    Of course, maybe this is not your problem, but it is a fairly well known one that more or less fits your description.
     
  7. Applewood

    Moderator Original Member Indie Author

    Joined:
    Jul 29, 2004
    Messages:
    3,859
    Likes Received:
    2
    Guilty as charged, sorry.

    Ok:

    If you're statically linking the CRT and not using other DLL's explicitly, then the answer is simple, "nothing".

    You sure you don't just have a release mode bug? Attaching a debugger makes a difference even on a release build to things like whether and how memory gets cleared on startup/allocs/etc
     
  8. TheMysteriousStranger

    Original Member

    Joined:
    Jan 17, 2006
    Messages:
    222
    Likes Received:
    0
    Ah, found the culprit - it was because I forgot to turn off the embedded manifest in the static build. This was obviously giving windows a headache.

    And of course it's never that simple. I now have another crash on the test computer.

    The static build will run just fine on the dev computer, but crashes during setup on the test computer (after creating the window, but before loading assets/displaying anything). I think the problem might be directX related, but the error message is a bog standard memory dump error. I tried updating to the latest version of the DX runtimes on the test computer, and ran windows update to ensure no outstanding compatibility issues, but no luck, it still cashes.

    So I would like to ask a favour of anyone reading this thread, could you download this zip file, extract the folder and run the 'd3d engine.exe' file.

    Download: http://www.oddgoat.com/temp/moneybags.zip (5.5MB)

    and let me know where (or if) it crashes. Either way, could you also let me know the specs of your machine (OS, video card), if you have VisualStudio installed (and which version/service packs), and what directX version you are running.

    Thanks in advance.
     
  9. MFS

    MFS New Member

    Joined:
    Feb 28, 2007
    Messages:
    314
    Likes Received:
    0
    Booted up like a charm for me :D Couldn't figure out how to play though, heh.

    Vista SP 1
    GeForce 6150SE nForce 430
    DX 10

    Visual Studio '05 Professional SP 1
     
  10. TheMysteriousStranger

    Original Member

    Joined:
    Jan 17, 2006
    Messages:
    222
    Likes Received:
    0
    Thanks MFS - and yeah, there's nothing to play yet. It's still very early in development.

    So it works on vista sp1. Interesting. I'm not sure if it's just because the laptop I'm testing on is so utterly old and crap that it is the problem, or if it's the code that's the problem.

    Hopefully a few more people will test the app and give me a better test sample (hint hint :D )
     
  11. MFS

    MFS New Member

    Joined:
    Feb 28, 2007
    Messages:
    314
    Likes Received:
    0
    NP, but, um, ahem....

    moneybags\data\meshes\commonTextures\*.png

    Is, um, interesting. Didn't spot that in the game though ;)
     
  12. TheMysteriousStranger

    Original Member

    Joined:
    Jan 17, 2006
    Messages:
    222
    Likes Received:
    0
    Haha, oops. Gone now (updated the zip). I suppose I should be glad that's an ex and not the current missus :eek:

    She (the ex) would rip my limbs off one by one if she knew I'd accidentally uploaded that to the web!

    That'll learn me to check what files are in the zip before uploading!
     
  13. TheMysteriousStranger

    Original Member

    Joined:
    Jan 17, 2006
    Messages:
    222
    Likes Received:
    0
    Ah, I think I may have found the problem.

    My choice of old crappy laptop is a little too old and crappy - it doesn't support non-power 2 textures! Plus I forgot to check for this feature during startup. I may have to re-tool the app to use power 2 textures. Hopefully that will allow the game to work on older machines without any hiccups.

    Thanks for your help guys, and special thanks to MFS for pointing out my uh... mistake :)
     
  14. MFS

    MFS New Member

    Joined:
    Feb 28, 2007
    Messages:
    314
    Likes Received:
    0
    Haha. That was a good laugh to start the morning, so thanks :)

    I guess that's what I get for snooping (I was wanting to look at your purple cloud textures!)
     
  15. TheMysteriousStranger

    Original Member

    Joined:
    Jan 17, 2006
    Messages:
    222
    Likes Received:
    0
    And nope - it wasn't the power-2 texture thing. So I guess I'm back to square one...well two technically.

    So if anyone is reading this, and would like to give it a test run on their system, the link is:
    http://www.oddgoat.com/temp/moneybags.zip (5.5MB)

    Again, a quick rundown of your specs if you test it would be appreciated. I'm really just trying to pin-point what it is missing on the laptop which is causing the crash, so I need more information about what it can run on.

    Thanks in advance.

    PS If it would sweeten the deal, I might even put the dirty picture back in ;)
     
  16. Applewood

    Moderator Original Member Indie Author

    Joined:
    Jul 29, 2004
    Messages:
    3,859
    Likes Received:
    2
    Sounds like you're missing a really good assert and logfile implementation.

    Write your own using a macro that dissappears in release (unless you define FORCE_ASSERT on the command line) and have it print the message on the screen, stdout, outputdebugstring and ideally to a logfile that's opened, seeked, written and closed right there.

    Then fill your code with "I got here" log output messages. Chances are the app will crash before you see the log/assert of interest if you're already checking the obvious, but you'll still find roughly where the problem is by checking out the ordering of the previous outputs.

    I had a problem with trying to create a PUREDEVICE device on those poxy intel cards a long time ago and scratched my head for ages. Logging showed me where the app got to and I cleaned the bug in no time after that.

    This is the output I make that comes out from my engine, just for an example. A lot of stuff chopped out for brevity - you get the idea.

    Raz0r Event Logger

    * RZCore_Base::RZCore_Base
    * Showing the Window
    * Make3DCaps:Begin
    * MaxPSInstructions=32768
    * VertexShaderVersion=3.0
    * PixelShaderVersion=3.0
    * Raz0rShaderVersion=3
    * Make3DCaps:End
    * RZCore::SetVideoModeFromDimensions 1024x768 (Windowed)
    * Trying to actually set video mode: (1024x768)
    * Finding depth-buffer format
    * Set to D3DFMT_D24S8
    * Creating D3D Device
    * D3D Device Created
    * Clearing the screen
    * Start RZVertexMgr::Init
    * Start RZFile::Init
    * Setting CWD to d:\Dev\Pool
    * Data folder=Data
    * End RZFile::Init
    * Before RZRenderTarget_Base::Init()
    * After RZRenderTarget_Base::Init()
    * Start RZAudioMgr::Init
    * End RZAudioMgr::Init
    * RZCore_Base init Complete
     
    #16 Applewood, Sep 17, 2009
    Last edited: Sep 17, 2009
  17. TheMysteriousStranger

    Original Member

    Joined:
    Jan 17, 2006
    Messages:
    222
    Likes Received:
    0
    aha, pure device - that might well be it.

    And yeah, I have a logging system, but had been putting off placing in the hundreds of log calls out of sheer laziness :) If it's not the pure device problem (which it may be, the laptop does have a shitty intel integrated chipset) then I guess I'll have to log the hell out of the app.
     
  18. Applewood

    Moderator Original Member Indie Author

    Joined:
    Jul 29, 2004
    Messages:
    3,859
    Likes Received:
    2
    Heh. No pure and use software vertex shaders if the original device create fails and you're done.
     
  19. TheMysteriousStranger

    Original Member

    Joined:
    Jan 17, 2006
    Messages:
    222
    Likes Received:
    0
    Well, I found the problem, and it's a doozy!

    Turns out the chipset in the laptop is so old, that it only supports shader model 1.4, and directX9 doesn't support less than SM2. Most chipsets would let you download drivers to support SM2 through emulation, but unfortunately this chipset is the old SiS chipsets, which they discontinued driver support for years ago.

    So basically I have no hope of ever getting the game to run on that laptop - it's just too old and craptacular. Time to fork out for a slightly newer one I guess. :(

    Oh well, if nothing else I've added several extra layers of fallback code to my game :) Thanks for the help guys
     
  20. Applewood

    Moderator Original Member Indie Author

    Joined:
    Jul 29, 2004
    Messages:
    3,859
    Likes Received:
    2
    Christ, that is old, nice one!

    In fact it's so old I'd expect it's value to start going up again :)
     

Share This Page

  • About Indie Gamer

    When the original Dexterity Forums closed in 2004, Indie Gamer was born and a diverse community has grown out of a passion for creating great games. Here you will find over 10 years of in-depth discussion on game design, the business of game development, and marketing/sales. Indie Gamer also provides a friendly place to meet up with other Developers, Artists, Composers and Writers.
  • Buy us a beer!

    Indie Gamer is delicately held together by a single poor bastard who thankfully gets help from various community volunteers. If you frequent this site or have found value in something you've learned here, help keep the site running by donating a few dollars (for beer of course)!

    Sure, I'll Buy You a Beer