Sorry your browser is not supported!

I wonder if anyone can help me with this one. I recently reinstalled a laptop with a clean XP installation. Now, my DBP app crashes as soon as it's launched: "... has encountered a problem and needs to close."

I'm developing the app on my Win7 PC. It runs fine on the Win7 PC, and on an older XP computer.

I have tried:

- Putting an 'end' at the start of the program to see if I can get the XP laptop to at least run the prog and exit smoothly. This works on Win7 and the older XP computer, but not the XP laptop (same result).

- Compiling the app on the older XP computer, then running it on the XP laptop. The app works on the older XP computer, but not the XP laptop (same result)

- Starting a blank project that just prints 'gtitjii!', waits for a keypress and exits. This WORKS on all 3 computers.

- Sticking my head in a bucket of gin.


The fact that the blank project ran leads me to believe that something is being included in the exe that is causing the crash on this particular installation of XP.

Also, this has happened before. I bought an old laptop home from work and tried to run a different program on it. Crash. Strangely enough, I tried the prog a few weeks later on that laptop and it worked?!? What's that all about?

I have DX9.0c installed, the Matrix DLLs are there, what is going on? Does anyone have any advice on how I can sort this out?

Thanks

(a slightly ranting) James

Because it expects something to be there which isn't perhaps - or it finds it but it's the wrong version?



Same here.

I've just been trying to tidy up some of my old fog shader demos - they all crash in much the same way as you describe, both the old exes and newly compiled ones. My newer demos all work and I don't know whether to bother to isolate the cause of the problems with the older ones. It's annoying because they use different methods and I wanted a performance comparison.



The first step is to narrow down the cause. You've already got something that works so I'd suggest adding features to it one at a time till it crashes consistently, e.g. try sound, images, 3D etc. Then see if you can narrow it down even further. That might not tell you the specific answer but it might give someone else a clue.

You might make more progress if you resort to the gin after you've solved the problem (that's a case of "do as I say not as I do" by the way ).

This sounds like the most likely culprit to me. What would be useful is the ability to watch the program start on the OS level, i.e. which files are opened, registry entries fiddled with, etc.

I used to have a program on the Amiga (them were the days) that would report exactly what was going on in the filesystem - it was invaluable. I wonder if anything like that exists for Windows. If we could see which files opened, we could compare them and isolate the problem.

Looks like we're going to need more gin.

James

Is the resolution that the project in question compiles at not supported by the laptop? Laptops generally have a smaller resolution than desktops so just check that the resolution is supported by the laptop.

Good question.

I've been caught by that one a few times when trying my old code on a new machine. It rarely happens now because I don't usually hard code the display mode values any more.

So have I when I transfer code from my 17.3" laptop to my little netbook. I still hardcode the display mode because my netbook likes a 16 bit resolution but will occasionally accept 32 bit. I don't know what's going on there but 16 bit seems to make no difference.

Hodgey - that's a good point, I'll have a play with that and post back.

As part of the prog's startup code, it checks whether the display rez specified in the settings is valid on the computer, and if it's not, it sets it to the desktop/screen rez. Saying that though, I'm not sure what it's actually set as when the program starts.

Thanks for the input... interesting!