Jump to content
XCOMUFO & Xenocide

X-com Crash With Xcomutil


Guest Sethwick

Recommended Posts

Guest Sethwick

I'm using Windows XP Pro Edition.

 

I've installed XComutil on the gold edition. I run things from runxcomw.bat and everything works fine, until I get into a ground battle. Normally, at this time, the game screen flickers and I see the desktop for a second, as Xcomutil does it's thing, then I get into battle. That's what I've seen on other computers that ran it fine.

 

Now, instead, the screen goes black, and then I crash to desktop with an Xcomutil command prompt window open. The window is black and the only thing you can do with it is close it. This happens every time.

Link to comment
Share on other sites

Guest Sethwick
Update: This crash does not happen if I window everthing using D3DWindower. However, when I use it, the mouse tends to screw up a lot, which makes it very ahrd to play.
Link to comment
Share on other sites

The mouse problem probably can be solved. Unless you understand the D3DWindower ui, all you can do is edit the config direcly. Open the file hook.ini with a text editor and look for UseCursor... variables, these are responsible for mouse behavior. I found the best results with ...Set=0, and ...Msg, ...Get, ...Clip all three =1.
Link to comment
Share on other sites

Now, instead, the screen goes black, and then I crash to desktop with an Xcomutil command prompt window open. The window is black and the only thing you can do with it is close it. This happens every time.

 

This sounds the same as what happens to me (going into or out of battle the game seemingly CTDs). Only because I am using XcomUtil, although I am not sure why it happens.

 

Anyway, when I am left with the RunXcomW.bat window sitting there, I just hit ctrl + c and Xcom goes back to what it was doing. You may have a different bug but it sounds too much like what happens to me. I'm not using any of the XcomUtil features like Autoresolve Battle and the like, so I can't understand why it needs to "CTD" before and after every battle. Immensely annoying, but at least it isn't an actual game-stopping CTD.

 

Give it a shot. It may be annoying, but better than a 320x200 window on a high desktop resolution...

Link to comment
Share on other sites

Guest Sethwick

Hmm, thanks for the Ctrl-C thing, I will try it later.

 

Thanks also for the mouse settings for the .ini. Unfortunately, after it worked fine for a bit, things started screwing up with D3DWindower too. It would do the same thing, the window would close, the "runxcomw.bat" window would come to the front and... nothing.

 

Xcomutil seems to seperate the geoscape and the tactical screen into two seperate programs, and when you go from one to the other it has to close one and open the other (i got it to work in D3Dwindower by including the "geoscape.exe" and "tactical.exe" files). For some reason, it almost always hangs here for me. Hopefully the ctrl-c thing works. I really like the addons xcomutil gives.

Link to comment
Share on other sites

  • 3 weeks later...

I had exactly the same problem up until 1 minute ago :)

CTRL+C works... But the following works even better:

[EDIT] Only worked once and never again so I've removed it. Zaimonis sollution below works much better.

Edited by bertilsson
Link to comment
Share on other sites

  • 6 months later...
Make sure wherever the xcopy command is, that it explicitly has the /y option afterwards. That prevents RunXcomW.bat from waiting for an interactive prompt.

 

YAY! YAY! BOOYA! THankewthankewthankew! I was getting carpal tunnel in my left hand from all the Ctl-C's. I now have feeling back in that hand! YAY! =b My right hand, on the other hand (no pun intended) was toast since I was like 14; oh well, that "batch file" will be forever corrupted... :P

Link to comment
Share on other sites

  • 3 weeks later...
I had exactly the same problem up until 1 minute ago :)

CTRL+C works... But the following works even better:

[EDIT] Only worked once and never again so I've removed it. Zaimonis sollution below works much better.

 

Pardon my ignorance, but where and how do you do that exactly?

Link to comment
Share on other sites

  • 9 months later...

I have this exact problem except that i downloaded my version:

 

"UFO - Enemy Unknown"

 

From *mention removed*

 

I'm running it on xp and i have to do this ctrl+c thing all the time which is really annoying. What is this xcopy thing? Its mentioned in the readme file about copying data off the CD but i dont have a cd of course, is this what its about?

 

Thanks

 

Edit by Zombie: Mention of site removed - X-COM is not abandonware.

Edited by Zombie
Link to comment
Share on other sites

  • 7 months later...

Sorry to bump such an old thread, but I'm running into the same problem. I have TFTD Gold Edition on Windows XP. When running the game with XcomUtil (through RunXcomW.bat), I get a game crash whenever I transition from geoscape to battlescape. Here's the text of the error message, if it's useful:

 

"X-COM: Terror From the Deep Gold Edition has encountered a problem and needs to close. We are sorry for the inconvenience"

Error Signature:

AppName: geoscape.exe AppVer: 1.0.0.1 ModName: unknown ModVer: 0.0.0.0 Offset: 00000000

It's repeatable, so if you want the technical information box copied and pasted, I can do that later.

 

At this point, I get a few pop-up dos windows for different xcomutil exe files, finishing with xcomutil.exe itself, which gives me a "16 bit MS-DOS Subsystem" error:

"NTVDM has encountered a System Error

The handle is invalid.

Choose 'Close' to terminate the application"

 

after which all that's left is a dos prompt (cmd.exe window) that can only be closed.

 

After editing RunXcomW.bat to add the /y flag to the xcopy commands (as in this thread, as well as the current one), It will eventually (after about 30-45 seconds) bring up the battlescape and become playable again. However, I'm running the DirectX Windower utility, and rather than coming up at the desired resolution, it comes up at the default (which is tiny). Upon completing the tactical mission, the game effectively exits (leaving only the dos prompt mentioned above).

 

Since this only seems to happen upon switching to tactical.exe, I assume the problem is either in the executable itself or in RunXcomW.bat. I've attached my copy of the batch file, but the relevant part should be:

 

:noexe2

if not exist patch.dll goto noldr2

start /w xcloader tactical.exe "1"

goto chklvl2

:noldr2

start /w tactical "1"

:chklvl2

 

since that's the only place where tactical.exe is invoked. I've tried a few basic things (removing the "1" didn't help), but nothing worked. It should be noted that I'm using f0dder's loader, so patch.dll does exist.

 

Also perhaps pertinent: using the default game exe works fine, as does xcloader (which invokes Terror.exe by default) and a command-line invocation of "xcloader tactical.exe" (need to test this more thoroughly though, I don't remember if this will spit it back to geoscape when i end battle).

 

I figure I must not be the only person running into this, so it's worth doing a little testing to see if we can fix it. If anyone has suggestions for what to fool around with, please fire away.

RunXcomW.txt

Link to comment
Share on other sites

  • 2 weeks later...

As explained in the other thread I linked, it's just to get XcomUtil to work in windowed mode. I run dual monitors, and running it in regular mode tends to make the second monitor unusable.

 

Regardless, it exhibits exactly the same behavior without the windower utility. Simply combining XcomUtil and the collector's edition of TFTD is enough to break it, even with the "xcopy /y" changes.

 

Also, in case this is of any use, I performed a few more brief tests of xcloader at the command line. "xcloader tactical.exe" brings up the battlescape as expected with no error, but will kick me back to the command line when I abort mission. In any event, this doesn't generate the error. Calling it with the optional "1" or "0" argument doesn't seem to change anything (what does this flag do by the way?).

 

"xcloader geoscape.exe" will bring up the main menu, but attempting to load a game saved in the battlescape generates the same error as attempting to recover a downed sub. Same result if the optional 0/1 flag is added.

 

This would seem to suggest that the batch file is fine, and that the problem is actually in the geoscape executable, specifically in the part where it handles the switch to tactical.exe.

Link to comment
Share on other sites

The split for TFTD was created by Scot with much prodding from me. it's an ugly hack and was only tested on the US release of CE.

If your version has ben modified the patch may have unexpected results. Or it could just be a bug.

Can you give us some specs as to your setup. Windows version. version of TFTD (was it an oficial release or warez)

Then can you email me a zip of your pre-xcomutil executable so I can see if I can rouse Scot on how to fix the issue.

 

-Blade FireLight

Link to comment
Share on other sites

Just to note: Bomb Bloke wrote an executable splitter/merger for UFO. If you pester him, he may be kind enough to do the same for TFTD. It really comes in handy especially for modders. :)

 

- Zombie

Link to comment
Share on other sites

Sure,

 

Windows version is XP SP2, TFTD is from the Windows Collector's Edition (Gold Edition) CD, bought retail a long time ago (5-8 years maybe? 10? has it been that long already?). I assume it's the US release, since that's where I live. XcomUtil reports this as "TFTDWIN 1.0 version of game detected."

 

I'm running the game off of a USB drive, but the problems occur regardless of the install location. Same thing happens on my P4m laptop and core 2 duo desktop at home, as well as the dual opteron and athlon xp systems at work. If you want more specific system specs, I can provide them.

 

I've attached the unmodified .exe from the install. Running the executable unmodified gives me the windows video bug detailed here, but copying xcloader and patch.dll to the folder fixes that. Installing XcomUtil on a fresh TFTD installation yields the error I reported in my first post. I chose "yes" for enabling f0dder's loader, but "no" to everything else in XcuSetup for this test.

Terror_From_the_Deep.zip

Link to comment
Share on other sites

Just to note: Bomb Bloke wrote an executable splitter/merger for UFO. If you pester him, he may be kind enough to do the same for TFTD. It really comes in handy especially for modders. :)

 

- Zombie

 

I will be sure to contact him.

 

Sure,

 

Windows version is XP SP2, TFTD is from the Windows Collector's Edition (Gold Edition) CD, bought retail a long time ago (5-8 years maybe? 10? has it been that long already?). I assume it's the US release, since that's where I live. XcomUtil reports this as "TFTDWIN 1.0 version of game detected."

 

I'm running the game off of a USB drive, but the problems occur regardless of the install location. Same thing happens on my P4m laptop and core 2 duo desktop at home, as well as the dual opteron and athlon xp systems at work. If you want more specific system specs, I can provide them.

 

I've attached the unmodified .exe from the install. Running the executable unmodified gives me the windows video bug detailed here, but copying xcloader and patch.dll to the folder fixes that. Installing XcomUtil on a fresh TFTD installation yields the error I reported in my first post. I chose "yes" for enabling f0dder's loader, but "no" to everything else in XcuSetup for this test.

 

Well that is the same exe as I have. I don't currently have XP at home. So I'm knee deep in creating an installer that can work in both vista and dosbox. Once I have a working install I will see if I can replicate your issue.

 

-Blade FireLight

Link to comment
Share on other sites

Got Blade's message and was curious as to what the request was for. Hate to dissapoint, but my code is really just a copy of Scott's function so it doesn't really help here.

 

Nevertheless I think I can help shed SOME light on the matter.

 

First off, the "encountered a problem" message is sometimes triggered whenever the game swaps engines (or tries to shut down). It happens to me often, usually ten or more times in a row, though other days it'll work fine for hours worth of gameplay. I heard it mentioned once that the cause was f0dder's loader (of which there are a few different versions - perhaps some don't cause the crash?).

 

I consider the best way to "fix" this to be by running the game with a split EXE (for example, via XComUtil). The reason for this is that the crash only happens when the game is actually trying to close down one engine prior to starting up another: And here's the brilliant bit, the game actually creates a special "hidden" save right before the crash (by coincedence), so all you need to do is manually start the next game engine yourself and it'll continue on it's merry way.

 

The batch file doesn't care how the last engine shuts down, it tries to start up the next one regardless (so you still get seemless gameplay once you've closed the error window), but if you're not using the batch file it's up to you to work out how to get the game to resume. Hence why I recommend using a split EXE run via a batch file.

 

But that doesn't help in this particular case as 1) you're already using a split EXE run via a batch file and 2) it's not the game that's crashing, it's XComUtil (or rather, the DOS VM that Windows runs in order to make DOS programs work, called NTVDM). For who knows WHAT reason NTVDM seems to run better on some systems then others. An example of one of the odd things it does is present on my computer - If I load up the DOS version of UFO and try to walk a unit down a ramp, NTVDM dies citing a CPU instruction error. The real pain in the rear is that when NTVDM crashes, it takes down the batch file that called it as well (unlike the "encountered a problem" message TFTD itself gives you, which allows the batch to continue).

 

So! What to do about it?

 

Well, first off you might as well find the EXACT point where the crash is occuring. To do that you'll need to edit XCU's batch file a little bit. First, chop off the first line ("echo off"). That hides most of the information from you.

 

Next, look for the terms ">>xcomutil.log" and ">nul". You want to remove them (as opposed to the lines they're attached to).

 

Save the batch, and then create a new batch file in your game folder. Call it "XCUcrashlog.bat" or something equally relevant. Load it up in Notepad (the quick way is to right click the new file and select "Edit" from the context menu), then put in this one line:

 

call runxcomw.bat > crashlog.txt

 

(Where "runxcomw.bat" is the file you run to start XCU, I think the name might really be "runxcom.bat" but I lose track).

 

Run that batch file and play the game until you get your NTVDM crash. Now if you look in the "crashlog.txt" file you'll see exactly what commands the batch file completed (along with their output, if any) prior to the point of that crash. Post that log here and hopefully someone will be able to recommend a fix. :)

 

Incedently, the "0"/"1" arguements are really for the DOS version of the game. If you tried to start the tactical or geoscape engine without using them they simply shut themselves down instantly. Of course, unless you were trying to do "fancy hacker stuff" you didn't WANT to run those programs individually anyway (you wanted to run the batch file, which then ran them for you). They don't do anything to the CE version of the game (to my knowledge), likely Scott was just doing some copy/pasting to speed things up and couldn't be bothered to chop them out later.

Link to comment
Share on other sites

Ok, ran the tests as described. I made copies of the crash log at several points, to make it easier to pin down the source of the error.

 

First test: Started the program, loaded a saved file that was on the battlescape. Encountered the error message, and made a copy of the crash log (crashlog-1-errorscreen).

 

Hit "close" on the error message, and made another copy of the error log while I was waiting for the batch file to do something (crashlog-1-aftererrorscreen). After about 45 seconds, the battlescape finally comes up. From the error log, it seems this delay is due to the program copying over a bunch of .dat files from \missdat\. To see if it was just a transfer rate issue (I'm running this off of a USB stick, as I mentioned), I copied the \missdat\ folder manually to the desktop in Windows Explorer - nearly instantaneous, which is as expected since it's only 67KB total.

 

Anyway, finished this test by aborting mission, going back to the geoscape and then choosing Abandon Game from the main menu, which triggers another crash. Hit "close" on the error message, and copied the crash log (crashlog-1-full).

 

Second test: Started program, and started a new game. Waited around for a sub, and sent out the Triton. Error message when the game tries to switch to battlescape (crashlog-2-errorscreen). After hitting close, I waited around until the battlescape loaded (again, about 45 seconds) to make the copy of the log file (crashlog-2-battlescape). Again, aborted mission, returned to geoscape, and abandoned game, triggering the final crash. Copied error log again after the cmd window closed (crashlog-2-full).

 

Third test: Just for completeness, I wanted to see if anything changed running off of the hard drive, so I copied the entire TFTD folder to the desktop, and repeated the second test from that location. The log files (crashlog-3-*) are taken at the same points. There was no discernible difference between this and test 2. I checked the log file at the error screen of the final crash to see if anything was added after I hit close. The last line at the time was:

C:\Documents and Settings\Chi4\Desktop\test\XCOM2CE>start /w xcloader geoscape.exe "1"

which means the last 5 commands were logged after the error occurred.

 

Let me know if there are any other tests I should run.

crashlog_1_errorscreen.txt

crashlog_1_aftererrorscreen.txt

crashlog_1_full.txt

crashlog_2_errorscreen.txt

crashlog_2_battlescape.txt

crashlog_2_full.txt

crashlog_3_errorscreen.txt

crashlog_3_battlescape.txt

crashlog_3_full.txt

Link to comment
Share on other sites

You were kinda vague about the error messages you got - Before you said you were getting "encountered a problem" messages and "NTVDM" messages, this time you just called them all errors. Since you were able to get the game to "work" (albiet slowly) I assume you're not getting NTVDM errors anymore? That's kinda random, but can't complain I suppose. The game is at least playable without them.

 

Did test 3 (from the HDD) still take 45 seconds to load the battlescape, after the error message displayed? Or is most of that time spent waiting for the error message to appear?

 

I took a look at that Windower program thread you linked, and noticed that you shouldn't need to use f0dder's loader with it. Perhaps that'll let you get rid of those last error messages - to disable the loader with XCU, just rename "patch.dll" to something else and it'll stop trying to use it.

Link to comment
Share on other sites

You were kinda vague about the error messages you got - Before you said you were getting "encountered a problem" messages and "NTVDM" messages, this time you just called them all errors. Since you were able to get the game to "work" (albiet slowly) I assume you're not getting NTVDM errors anymore? That's kinda random, but can't complain I suppose. The game is at least playable without them.
Yeah, sorry. This last time all of the "errors" were of the "encountered a problem" variety. I haven't gotten any more NTVDM errors.

 

Did test 3 (from the HDD) still take 45 seconds to load the battlescape, after the error message displayed? Or is most of that time spent waiting for the error message to appear?
Yeah, it still takes ~45 seconds after hitting close. The error message takes almost no time to appear, it seems the delay is due to the game loading a bunch of .dat files. It doesn't seem to start loading these files until after closing the error message, so I assume the game will just sit there indefinitely until you do so.

 

I took a look at that Windower program thread you linked, and noticed that you shouldn't need to use f0dder's loader with it. Perhaps that'll let you get rid of those last error messages - to disable the loader with XCU, just rename "patch.dll" to something else and it'll stop trying to use it.
Tried this, and you're right, it works without f0dder's loader, but the error messages still occur at the same places as before (geo->battlescape, and exit game).

 

When I get time, I'm going to do some more testing on different hardware, just to see if all of this is repeatable or if it's tied to something system-specific. I'll let you know if I find anything interesting.

Link to comment
Share on other sites

A day or two ago I sat down and made my EXE splitter work with TFTD (same as with UFO, I just logged what XcomUtil did and then wrote code to copy it). Noticed that the wretched thing really does crash a lot.

 

In fact, the split Tactical file worked fine, but the GeoScape module ALWAYS crashed. Worse yet it never spat out an error code. I always just assumed that TFTD's split worked just as well as UFO's, but it looks like that's not the case. :S

 

But that doesn't account for the long wait time after it crashes. If you run that edited XCU batch directly (as opposed to using that "XCUcrashlog.bat" file I got you to make), you should be able to see exactly what it's doing as it does it (and hence see what's taking so long).

Link to comment
Share on other sites

The split is a really ugly hack. the exit code never set the errorlevel right so Scott had to look at time stamps and other info in the missdat folder to see if you were exiting the game or starting tactical.

 

What we need is some one with the skills to figure out the correct offset for the exit code.

 

-Blade FireLight

Link to comment
Share on other sites

If you run that edited XCU batch directly (as opposed to using that "XCUcrashlog.bat" file I got you to make), you should be able to see exactly what it's doing as it does it (and hence see what's taking so long).

Just checked, and doing that gives me the same result as the crash logs I uploaded. When I get the windows error message, the last command was

 

start /w geoscape "0"

Once I close the error message, it quickly churns through

start /w sdump QuietMode missdat\mission2.dat newer missdat\saveinfo.dat 

if errorlevel 1 goto end 

if exist xcuhook1.bat call xcuhook1.bat 

start /w xcomutrt missdat 

if not exist chgufo1a.xcf goto endchg1a 

if not exist chgufo02.xcf goto endchg02 

start /w xcomutil missdat wrt  

if exist xcuhook2.bat call xcuhook2.bat 

echo ------------------------------------------------------------------------  
------------------------------------------------------------------------

 

After which it cranks through the following very slowly, ~ 1 second per dat file.

 

xcopy missdat xcubef /y  
missdat\saveinfo.dat
missdat\mission2.dat
missdat\unitpos.dat
missdat\uniref2.dat
missdat\obpos2.dat
missdat\code.dat
missdat\geodata.dat
missdat\option.dat
missdat\unipos.dat
missdat\uniref.dat
missdat\obposref.dat
missdat\mission.dat
missdat\loc.dat
missdat\craft.dat
missdat\soldier.dat
missdat\base.dat
missdat\project.dat
missdat\research.dat
missdat\product.dat
missdat\lease.dat
missdat\bprod.dat
missdat\transfer.dat
missdat\purchase.dat
missdat\missions.dat
missdat\diplom.dat
missdat\alien.dat
missdat\xcom.dat
missdat\site.dat
missdat\up.dat
missdat\facil.dat
missdat\astore.dat
missdat\aknow.dat
missdat\xbases.dat
missdat\zonal.dat
missdat\acts.dat
missdat\inter.dat
missdat\uiglob.dat
missdat\liglob.dat
missdat\iglob.dat
missdat\direct.dat
40 File(s) copied

 

And finally, quickly executes

goto notbef 

if not exist ufoexe\geoscape.exe goto noexe2 

if not exist patch.dll goto noldr2 

start /w tactical "1"

Link to comment
Share on other sites

Certainly out of the ordinary. Sorry to say that's a fault specific to your system; there isn't much that can be done about it by tweaking XComUtil. Very odd that it does this when running the game from the HDD.

 

See, my system copies those files in about the same amount of time it takes for me to blink.

 

Three things I can think of from the top of my head.

 

1) Right click partition (eg C:), select Properties, go to the Hardware tab. You'll see a list of the physical drives installed in the computer. Select the one TFTD is on, hit Properties. You'll get a new window, select the Policies tab in that, and you'll see an option to enable/disable caching.

 

The purpose of this is so that whenever the computer goes to write to the drive, instead of sending the commands straight to it, the commands instead go to a cache (and then they're carried out in the background). Basically this means the operating system doesn't have to sit around waiting for the transfer to complete, and hence neither do you.

 

It's a bad idea to enable this for removable disks (such as a USB thumbdrive). Say you go to copy a file onto such a device, the operating system will report it took a second or two (and let you get on with whatever it is you want to do), but the actual copying process will continue for some time. If you accidentally unplug the drive before it completes, you've messed up the transfer. Windows 2000 turns it on for removable drives by default, Windows XP does not.

 

On the other hand, you should have this on for all drives installed inside your computer (as you shouldn't be unplugging those without powering down the system anyway, and shutting down Windows ensures that all caching operations are first completed successfully). I believe all versions of Windows have this enabled for permanent drives by default.

 

2) Your IDE BUS might be running in PIO mode. This simply means the system is using less resources to deal with the HDD then it could be, and so things run slow. To check this, right click My Computer, select Manage. In the window that turns up, select the Device Manager and check out the IDE adapter list.

 

You'll see a primary and perhaps secondary channel listed. Double click each, in the new window select the Advanced Settings tab and make sure the Transfer Modes are all set to "DMA if available".

 

3) Your laptop isn't plugged into the mains and is running in power saving mode. I've heard of this being more of an issue with Vista, but apparently this can dramatically lower certain aspects of system performance in order to preserve juice. If you're relying on the batteries, hook up the power adapter and see if it makes a difference.

 

Failing those three things, wipe the problem line from the XCU batch, see how things go without it. I suspect it's got something to do with the time/data stamp Blade mentioned, but I do know previous versions didn't actually include it.

Edited by Bomb Bloke
Link to comment
Share on other sites

  • 3 weeks later...

Sorry for taking so long to get back here, been too busy to mess with this lately.

 

All of the internal drives have write caching enabled, and are operating in the highest UDMA mode they're capable of. I'm certain it isn't a drive-related issue, since the files copy properly (and quickly) when done through windows explorer or command line. It only seems to slow down when the batch file is doing it.

 

Also, the laptop was plugged in for all the tests, so no power saving mode. All of these machines run XP.

 

I'll post back here when I get time to test it without the geoscape line.

Link to comment
Share on other sites

  • 1 year later...

Hi i am having the same problem as some other people had in the past reggarding the Ctrl + C issue; and i've read your explination with the /y but i am really puzzled where that thing should go...

 

(plus i've seen at least 2 other people asking the same question and no reply added to them...)

Link to comment
Share on other sites

I am sorry, maybe i am not asking the question rightly, anyway i managed to figure it out:

 

Go to the batch file (RunXcomW.bat or whatever the file name is) right click on it, and click on the EDIT option, this would open it with a notepad after that i would suggest to make things easier; to go to

 

1 - edit

2 - find...

3 - type in xcopy (direction should be from "down" you being at the begining at the page)

4 - just add after every xcopy you find a "y/"

 

example: "xcopy /y xcubef missdat >nul"

 

I hope i've not been confusing with all the instructions, if they are you can allways eye-search the notepad manually for the xcopy.

 

I've found this problem to be quite common; xcomutil should be updated regarding it.

 

Cheers and good luck !

Link to comment
Share on other sites

  • 2 weeks later...

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...