your using the actual CD for the launch, ie its in the drive when you try it?
is the CD your using a copy or genuine copy?

EDIT: the drive you are using is an actual drive mounted to the system or one of your other external ones?

try uninstalling and reinstalling, so what happens

The log is below, I already did uninstall and reinstall once before, will try again if you wish.  I may have a little time this evening, I will trace the executable and see if I notice anything overly odd if I can.  Out of curiosity, what does your executable do exactly?  I notice it links winsock, does it handle mini-dump uploading or something?


EDIT 1:  Okay, this is funky wierd, I *know* I see traces of Visual Studio (7.0, maybe 6.0, but I think 7.0, really should upgrade to 7.1 at least, *far* more complient), yet I see so much of delphi layout as well, causing a lot of hopping around (hits the cache rather hard, should not do it, although the program does not do much so not really necessary to worry about).  There seems to be a *massive* amount of unused code path's and resources, bloating the code far larger then what is necessary.  Although some of these might be accessed through function pointers rather then direct links, but that is quite rare.  Still have not yet run it, may not have time...

EDIT 2:  Traced a bit, seems to churn something 5000 times, once done, performs more things (seems to call destructors of class-like structures to clean up things, like the window) and quits, digging more into that loop (don't suppose you could say what it is doing, maybe checking for armada2 startup or something?)...

EDIT 3:  (Mostly my own note taking):
In the loop, which exists inside the exe and not a linked library:
It calls a function in user32.dll (to be figured out, 0x4AF818).
Then makes sure the return value is not zero (which it always is thus far, would jump away if it was not zero at this point).
Then calls a function inside the application itself (seemingly to make up for the missing library function), this function then jumps into kernel32.dll (0x7c802451)
After the kernel function returns it then jumps back and repeats the loop, no test after calling the kernel function, the kernel function probably sleeps or something (to be checked, now checked, SleepEx called with a value of 1).

EDIT 4:  Kernel function checked, it is SleepEx, set above, checking the user32 function now...

EDIT 5:  Have not yet figured out what the user32 function is that is called, but the purpose of this is that I notice that the log is in the middle of its "Post launch" sections when I terminate the trace inside the loop...

EDIT 6:  Got more time to look, the function in the linker map for user32.dll is at location 0x1E581, which corresponds perfectly to the ASCII version of FindWindow (FindWindowA), and the params passed match as well (pass a null pointer for the class name and pass a pointer to a string {"Armada2\0"} for the window name param).  So, the 5 second long loop tries to access the window named Armada2, if not, it sleeps for a millisecond (which will not actually sleep, just toss the context switch around to give other processes cpu time if need-be), and then loops.  If not found within '5' seconds (in quotes because, as stated, the context switch will just be thrown around, possibly taking more then 1 millisecond, sleep is highly unreliable when used as timing on a granularity smaller then ~24ms, so it usually takes between 10-12 seconds in reality), it dumps out, cleans up everything, and dies.  I wager I will find CreateProcess sometime before the loop is called, havn't checked, probably where the problem is however, will check later, I only had a minute to spare here...

EDIT 7:  Before I need to go, just remembered something...  Why is the window handle being looked for, and in such an active mannor as well?  Only reason to need the window is to inject events directly into to.  If you are just going to watch for when the application closes then you can get the process handle from CreateProcess when you launch the app, then just put a lock on it so the launcher freezes until the app closes, then when the app closes the launcher continues on as if it never stopped, just now instantly knowing the app is gone (handle is now invalid).  Using that handle, before you put a lock on it or what-not, you can do a wide variety of functions on it, far more power then just a window handle, even injecting events into the process itself (rarely a reason to inject directly into a specific window and not an entire process).  I have to admit that I am a tad bit confused as to why FindWindow is being called at all?  Either way, need to go, talk later.

Ah, that makes sense, although I would just listen to the windows being created and got a handle on it then (this is an async operation so you can still have the main part of the program block on the armada2 process until it closes and still do everything to the window that you want so as to not have a comparatively expensive loop).  I added you to msn, I basically never use it, my main is GTalk, but it is up currently.

strange, the log seems all fine to me until that cut off line..

you have to reboot your computer after starting fleet operations?

uninstalled and reinstalled... still no go

[11/17/06 - 15:54:41] Fleet Operations Loader Log - initialized
[11/17/06 - 15:54:41] © 2003-2006 Fleet Operations Development Team - http://www.fleetops.net
[11/17/06 - 15:54:41] Pre Launch - Full Parameters list:
[11/17/06 - 15:54:41] Pre Launch - Initializing cursors stage 1 (non zero value expected): -1
[11/17/06 - 15:54:41] Pre Launch - Initializing cursors stage 2 (non zero value expected): -1
[11/17/06 - 15:54:41] Pre Launch - Initializing cursors stage 3 (non zero value expected): -1
[11/17/06 - 15:54:41] Pre Launch - Initializing cursors stage 4 (non zero value expected): -1
[11/17/06 - 15:54:41] Pre Launch - EditorMode False
[11/17/06 - 15:54:41] Pre Launch - Chosen Splash \FOData\Splash\Splash1.bmp
[11/17/06 - 15:54:43] Pre Launch - Splash effect enabled
[11/17/06 - 15:54:45] Process launch - Version number refreshed
[11/17/06 - 15:54:45] Process launch - Path to executable C:\Program Files\Activision\FO\
[11/17/06 - 15:54:45] Process launch - Executable Command line "C:\Program Files\Activision\FO\armada2.tgt"
[11/17/06 - 15:54:45] Process launch - Path to executable exists -1
[11/17/06 - 15:54:45] Process launch - Reported Process ID 1364
[11/17/06 - 15:54:45] Post launch - 7315536/1364/504/-1
...
[11/17/06 - 15:54:45] Post launch - 7543676/1364/504/-1
[11/17/06 - 15:54:45] Post launch - 75436

cut off as you see it...

HA! I created a new administrator account and it worked!

I suppose the question is what is interfering with the game in my primary account?