The problem has also occured with a Windows ME using PC and a Windows XP SP 1 using PC.

Perhaps you could try catching exceptions in each place you construct objects (including the ifstream). Also, depending on the compiler and the options you compile or link with, failed memory allocations may not return null. Are you using inheritance at all? If so, problems could be occuring in the base class.

Well, try to isolate the problem. Comment out all the code in the constructor. Is game NULL? Can you call its methods? Do they work? If yes, comment out just the creation of BoNoptions. Does the rest of the code get executed? And so on. Then tell us the results :)

I've already isolated the problem to BoNoptions. But I guess I have no choice but to send my helpful customer tons of test builds. I would have already tried a lot more things if I could test the problem myself.

Quote:Original post by Tertsi
I've already isolated the problem to BoNoptions. But I guess I have no choice but to send my helpful customer tons of test builds. I would have already tried a lot more things if I could test the problem myself.

You could ask him to allow remote desktop connections to his computer and then run the code through a debugger. Also, posting the declaration of BoNoptions could be helpful. Do any other BoNoptions' methods cause a crash?

Tertsi-

If you're going to carry out test builds, then I would personally meticulously pull out and centralize all globals first and put them in a header file. If you're using Linux or can download a copy of MinGW, then you can easily 'grep' and/or 'sed' all your source code and do this quickly.

Then I would check the backward compatability of the compiler/api to all these various Windows OS's. You might want to upgrade. This investigation could be done on the MSDN website.

I personally don't think that the problem is isolated to 'BoNoptions'. It could be that it is a result of something that 'BoNoptions' is trying to access, and, if this is the case, it could pop up again somewhere else later.

Additionally, I would also contact my client and ask them first to check the Ram and DLL's in these failing machines. There is a simple memtest.exe program that can be downloaded for free, which can be put on these machines overnight with results available in the morning. Is it also possible for your client to reload the Windows version on these machines, to ensure that a critical dll isn't corrupted?

--random

Other thoughts...if your client is using high-performance gaming machines (like I have in the past) the voltage to RAM is crucial during high demand processes (such as intense numerical computations). I've actually had to lower RAM voltage through the bios to solve this problem. Not all machines allow this to be adjusted.

Further, the crash could even be due to another program on these computers that has a memory leak. Is your client running any other apps in the background? Ask himm to check the services on the WinXP machine that crashes, and send you a list. There was a problem with multiple copies of certain services running in early versions of Windows (SP1) that was corrected in SP2. I think that this was svhost.exe, if I'm not mistaken, but you can check this on the Microsoft website. Ask your client to restrict the start-up (memory resident stuff) on these machines, then try again. Sometimes these things can go unnoticed for some time, until a new software package places a high demand upon machine resources.

--random