Sign in to follow this  

runs at home but not on some work pcs!

This topic is 4866 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

My game is simple, it runs well at home. So I zipped it all up and took it to work. It ran fine on my pc at work (after downloading glut32.dll and openal32.dll and installing the latest graphics card drivers). It didn't run though on anyone else's pc at work. They downloaded the latest driver, glut32.dll and openal32.dll. However, on starting it crashed every single time with error reading 0xcdcdcdcd - which we all know is baaaad !! The only thing I can think of is maybe I've used an extension that isn't supported on their card (although I'm sure I put all this stuff behind flags). So without me taking my entire code to work and taking over someone else's machine - how can I know what the problem is ?

Share this post


Link to post
Share on other sites
It's really hard to answer these types of questions without knowing anything about the code or the computers you are testing.
So, a general answer would be to make sure all of the files that your app references are actually there. Do you check all the files that you try to open in your code? There might be a place where you start reading a file that isn't there.
Maybe those machines have less memory and they run out. Do a little debugging (which I know is annoying because it's on someone else's machine) and see if you can narrow down the problem a little.

Share this post


Link to post
Share on other sites
ok, what I did was clean the area of my pc at work, I took the precise zip file my colleagues had and put it in my pc and unzipped. The game worked first time !
This is really annoying !
So it isn't the files...

Share this post


Link to post
Share on other sites
Take a debug-build to work and make it spew everything to a log file. When it breaks on your colleages machine you can see where the last succeeded code was called and make assumptions from there.

Aside from that, just make your code more robust: check to see if calls to functions succeed and do something that will be more tolerant. Do checks for NULL parameters and NULL pointers before dereferencing them. If you use shielding (#ifdef BLAH) you might be bypassing code sections by accident that need to be called (eg. initialization of a structure).

The 0xcdcdcdcd sounds like you're using a pointer member of a structure without initializing it after mallocing it. When you call malloc it fills the memory with 0xcdcdcdcd (c=created I think) in debug builds and when you free something it fills the memory with 0xdddddddd (d = destroyed I think). If you're using constructors with classes and passing them not as pointers it's possible that your copy constructor isn't setting correct data.

Other than that, don't trust any functions to succeed. When they do fail, do something that isn't going to break the rest of your program.

Helped? :)

Share this post


Link to post
Share on other sites

This topic is 4866 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this