So, about once a year or so (this is the third year running?) I decide I am in the mood for Armada 2 (actually just cleaning up and come across the cd).  The fleetops launcher launches, it then launches Armada2.tgt, the armada2 application (the armada2.exe renamed to armada2.tgt file) then closes within one second, and the fleetops launcher spins for a few seconds waiting for A2's windows to spawn, after a bit it bails and closes.  If I launch the armada2.tgt file directly it opens then closes within a second, never a window, splash screen, anything ever popping up.  Open it in a couple debuggers and I am inundated with thrown exceptions, the primary of which is access to invalid memory, specifically:  "Unhandled exception at 0x7c90eddc (ntdll.dll) in Copy of Armada2.exe: 0xC0000005: Access violation writing location 0x00030ff4.", which is not exactly an error that should ever happen.  The place it occurs is at: ntdll.dll!strchr()  + 0xd9
So it appears to be a buffer overflow perhaps, not null-terminated, something?
Kind of looks like it happens after loading some dll, did not really look into that, but it is quite obviously the same error that has been occurring for the past couple years for me (even on a different windows install).  No that new launcher in the Vista thread does nothing (did not expect it to anyway, not a launcher error, it is an armada2 executable error).

So any help with this?

Doca, I think I still have you under my IM list, message me and I can setup my system for remote debugging if you are capable of doing so (as in you have the A2 source) so you can see exactly what is occurring.  I support VS6, VS2k3, and VS2k5, take your pick.

It is I from above, apparently there are some issues with your Joomla bridge with SMF:
When I try to login I get a blank white page, if I view source then I see this:

<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1" /><script>alert('This username/password already in
use. Please try another.
/www/htdocs/kunden/fleetops/administrator/components/com_smf/admin.smf.class.php
createJoomlaUser
577'); window.history.go(-1);</script>

I was logged in just fine a few minutes earlier.  Also does this in
other browsers.
Also, that javascript will not execute since it is not in an html
element (not in firefox, not in Opera, not in IE...).

Either way, back to topic.  Yes, of course, probably been reinstalled and tested well over 100 times over the past three years, remember, I have tried many different things, so I am mostly just looking for something now directly for this issue.

Reinstalled normal A2 as well, patch 1, 1.1, and your 1.2.5 patch, none work, just shows the little splash image, then it disappears as well as the process.  Don't suppose someone could compare their pre-patched (version 1.0, straight install from CD) Armada2.exe file with mine to make sure mine is not corrupted or something, here are some hashes you can compare with, pick whichever you want, I know it worked at one time (obviously...):
CRC: 65236FCA
MD5: D4884BA6B5994B6E6BF1E49A9224785C
SHA-512: C15EDFE0B5DF142B8C57E3530C40EBE3D0D5FEA4CC91FAB525B668702F245B972BE01A02ECAB678D43E2CB2512CAB2C1122DEB65DEFBEC3089ECAEACFE28941D
Whirlpool: 6DB6D422BB381E2DC32EDB5F16F886753881CC13A3F8938D27DAD65D095E98B96734A19C8B1641A4310B8EC40376FA822EC54999651589F52F5E5E73BD06002A
Posted on: May 25, 2008, 04:25:17 AM

---

Few days later, hence the new post, did some debugging on normal A2 with your latest 1.2.5 patch.

First test in the debugger:
   Program Start.  Reference:  0059E800
   Hit two function calls, did not trace into them.  Reference:  0059E813 and 0059E829
   Right after the second call a pointer to an embedded string "bugs@fleetops.net is stored into the register EAX.  Two more function calls occur (had a single LEA between them), did not trace into them.    Reference:  0059E838 and 0059E841
   Then another pointer to an embedded string "Armada 2 bug report" is stored in the register EDX (and a few more regs are filled with other data) and another call occurs.  Right afer another call occurs, this call causing the splash screen to pop up for about one second then disappear, seems the return value of the function is stored in EAX, which is zero (0) on my test.  Reference:  0059E850 and 0059E856
   The next instruction sets EAX to zero, pops the stack a few times, puts a few other things in registers and calls another function, did not trace into.  Reference:  0059E876
   A return instruction is then called which jumps, oddly enough, down past the end of this function (3 instructions, this is probably the main routine with the compiler-baked functions).  Reference:  0059E87B, jumps to 0059E883
   It 'returned' to obviously very invalid data, thus the exception I read earlier and the program basically segfaulting.  Reference:  Crash occurs on 0059E888

Here is the relevant assembler of what appears to be the main function:

On doing the next run through I go into the 0059E856 call (the one that spawned the splash screen) to try to further see if I can find anything that you can match to source code to help figure out what is up (would probably be easier if you just wanted to remote debug into it though ).
   Lots of little things being done, lots of function calls, pass a function that passes the pointer to a string "Armada.Execute" pretty early to help you get your bearings in the source, then realized that I was debugging into another loader app and not A2 (what is with the loader apps?) due to the Kernal32.OpenProcess call.  I then decide to run Armada2.Execute for obvious reasons...  Ignore the above I guess...


So, now running Armada2.Execute:
   Wow, ugly freakin code, and a few exceptions being thrown even before the main loop is called thanks to some loaded dll's.
   Once I got past those it seems the main app starts about at 00665E66.
   The app installs a low-level structured exception handler to catch all uncaught exceptions, always a good thing (which your loader does not ever do I notice), ugly code, but well worth it.
   Runs through some more of the standard Pre-WinMain crap it looks like.
   It then calls some function deep within ntdll which then calls a function in non-readable memory (that is a new one on me...) thus even telling it to skip it does not work... how fun.  Seems to be in ntdll.KiFastSystemCallRet, probably an exception handler, past the stuff I want...
   Think I found the program's main function at 0046F720, so starting at this point now (this is before the non-readable error as stated on the previous line):
   It first outputs a standard debug string of "NDEBUG defined.\n".
   It then creates then shows a window of Class type "Armada2Splash" (using my powers of deduction, I would have to say that this is the splash screen ).  It then sleeps for 300ms for whatever reason (15ms should be fine to ensure a windows creation, or 35ms if on a 9x system, 300ms is way overkill, but whatever).
   A few calls after that the program dies again, starting to trace into functions before that now:
   This first one I follow seems to create the logging functionality by getting the time information, creating a log file (seems to have support for datestamped log files too, which is does not use for whatever reason), and so forth.  This function works and returns fine though it seems.
   Next it oddly pushes a function pointer on the stack and calls another function, somewhere in this one is where the crash occurs, so tracing into it now:
   In this function the first thing it does is set the low-level exception handler to an internal function that seems like it may be backed into this function itself, with a big ol' switch statement/table (and by big I mean big, it is FB in size).
   It then calls a function pointer (looks like it might be the one that was passed on the stack, but did not really check close for sure).  Somewhere in this function is where it crashes, so tracing into this one now, seems this function starts on:  0046F810
   The first call in it is where the crash occurs, now tracing into it, this function starts on:  0047D5B0
   Seems to set some low-level keyboard hooks (very odd I must say... usually will not work on non-admin accounts, but it looks like it has a fallback for that, so no big worry, but why use an llhook at all then?).  No problems to here though.
   It then does things like set its AI and Missions directory to the PATH environment var (why? any good game filesystem will not need nor use that...).  However this is where things seem to go wrong, let me elaborate:

It is effectively calling sprintf like this in C code:

As you can see, by my guess it seems that my system environment path of length 1721 characters is probably overflowing the buffer (which I bet they naively put at 1024 >.<; ).  I am now going to test this by launching a2 through a command prompt while cutting my path to a normal couple hundred chars (just enough for windows to function well for A2 for certain).  If it runs this is the problem, if not this problem still needs to be fixed regardless as it is a pretty bad bug, static buffers for external data, horrible horrible HORRIBLE mix, bad bad A2 programmers...
...
Now I test...
...
AND IT WORKS, THANK GOD.

Aren't you glad to have an external programmer/debugger sometimes.
Either way, I found a work-around, I'll just create a batch file to pre-set my PATH envar to something good for my system, you should have your patch fix that little bug in the next version because that is a pretty freaking huge bug that nothing else seems to have, probably because 'most' programmers learned long ago the horrors of static buffers with external data.

So yes, I gave you a detailed problem, the debugging path I went, and the fix, you have no excuse to fix; heck, if you want I could manually create the assembly in the executable to do it and have the function jump to that and back to fix the bug, I have done it in other commercial apps to fix bugs that are no longer being patched so I am no stranger to it, but as you are making newer 'unofficial' patches, this is something you really need to fix.
If you need help, email me at my username (OvermindDL1) at the normal gmail address.

I still cannot believe it was something as simple as a buffer overflow, some programmers really are lazy, wonder who originally wrote that function, guh...
Posted on: May 29, 2008, 02:33:50 AM

---

Also, I still cannot log into my OvermindDL1 account, still with the same above error, do not suppose you could fix that too, should be a simple DB edit (I've messed with the bridge before that you are using and encountered that bug, thought it was fixed long ago though, it is caused by changing your email address in your profile...).
Posted on: May 29, 2008, 02:35:44 AM

---

Also, if you are really cheap (and I really do *not* recommend this, but if you are going to do it, at least do it right), you could just have your loader set the envar PATH to "%WINDIR%\system32" and it should work in 'most' circumstances, but maybe only do it if you detected the path being too long in the first place, say more then 500 chars to allow for the max path of 256 for the each of the passed in A2 directory strings and a little for the format string.  Although this would work for anyone who does not have 'too' unusual of a setup (mine may be unusual, like my boot drive being F and so forth, but it is not *that* unusual for that to not work ), but it would not always work, and it would still be best to do the real fix I documented above.
Posted on: May 29, 2008, 02:53:21 AM

---

Yes yes, another thing, sorry...

I see resolutions like 1280x960, but I do not see 1280x1024, is there some file I need to change or something?

you should be able to login with your old account now, however you need to use the 'lost password' form as i had to reset it.

if you still have login issues, you can write me an email directly or contact me via IM

btw. welcome back to the forums