'Pre'launch error
1, 2
posted on May 28th, 2009, 12:20 pm
Last edited by OvermindDL1 on May 28th, 2009, 1:13 pm, edited 1 time in total.
posted on May 29th, 2009, 10:51 am
posted on May 29th, 2009, 11:06 am
posted on May 29th, 2009, 2:21 pm
I noticed that wrapper and it does get past loading it in, but by the time the crash occurs it seems the state seems a bit corrupted so it is *really* hard to follow (especially by the time it starts jumping into inaccessible memory, bit of an indication that something is corrupted by then).
Thanks for the idea though, if I remove (well, rename) your d3d8.dll wrapper then the executable launches, creates a window (meaning it reaches well into your winmain function, well, actually it just popped up and disappeared like before since the long path was not fixed, so using my temp fix that I used for your old version I got it to pop up a window), however it creates the fullscreen window, then an unhandled exception killed it. If I use your launcher it does the same thing (apparently an exception is happening that is not caught by your error handler). Running it through a debugger (after remember to set the environment for the debugger to shorten the path as well, A2 *really* needs that bug fixed) reveals that the exception is that it tried to derefence 0x0, which, obviously will not work.
The line that failed at is 0x0059D125, and I am pretty sure it was calling a function to load a bik file since on the stack there was a pointer that pointed to the embedded string "bitmapsmainsingleplayer.bik" as the second argument to that function (gotta love C-style function calls, so easy to figure out).
Apparently there is a function in the Bink library (_BinkOpen@8) that is passed that string then it then supposed to return a pointer, but the pointer is null, which then the line after the next is the above mentioned instruction, which then dereferences the null pointer, if I drop in the missing .bik file from an actual A2 install then it passed through this fine. If I add in those four bik files then I can get to the main menu just fine.
So, I am guessing that your wrapper is supposed to load up different movies or do something different, but the wrapper is rather horribly corrupting the memory state of the program. I should have been asleep, oh, 4 hours ago at the latest, so I do not have time to diagnose it now, but for later I would *love* it if you could give me any info on your wrapper file and what else it does and loads so that tracing through it will be easier later, hopefully looking into what it will be overwriting in memory because it is apparently overwriting something wrong, possible messing up the dynamic link table of the program (since that is where the program jumps into invalid memory is from the dynamic link table, can definitely tell A2 was compiled by an old compiler looking at that assembly).
If you need any help with code of such things, I have been doing this for years and the past week is the first time I have had free time in near a year, it may not last too long though, so if there is anything I can help with, feel free to ask.
Also, I noticed something odd, the splash screen that A2 pops up for a second while it first loads, is not a normal A2 picture, in fact it is the handle of another program that is currently running on my system, meaning that I bet the handle for it is also corrupted and it is by random chance picking a handle that is actually used by another image on the system (rather then like a file handle or a mutex handle or, you know, a handle that is not defined), I plan to look into that as well since it may also indicate where something is getting corrupted.
Either way, yes, the d3d8.dll hook, something it is passing off is royally screwing up memory, will try to figure out more later, for now, sleep, have work in a few hours...
Thanks for the idea though, if I remove (well, rename) your d3d8.dll wrapper then the executable launches, creates a window (meaning it reaches well into your winmain function, well, actually it just popped up and disappeared like before since the long path was not fixed, so using my temp fix that I used for your old version I got it to pop up a window), however it creates the fullscreen window, then an unhandled exception killed it. If I use your launcher it does the same thing (apparently an exception is happening that is not caught by your error handler). Running it through a debugger (after remember to set the environment for the debugger to shorten the path as well, A2 *really* needs that bug fixed) reveals that the exception is that it tried to derefence 0x0, which, obviously will not work.
The line that failed at is 0x0059D125, and I am pretty sure it was calling a function to load a bik file since on the stack there was a pointer that pointed to the embedded string "bitmapsmainsingleplayer.bik" as the second argument to that function (gotta love C-style function calls, so easy to figure out).
Apparently there is a function in the Bink library (_BinkOpen@8) that is passed that string then it then supposed to return a pointer, but the pointer is null, which then the line after the next is the above mentioned instruction, which then dereferences the null pointer, if I drop in the missing .bik file from an actual A2 install then it passed through this fine. If I add in those four bik files then I can get to the main menu just fine.
So, I am guessing that your wrapper is supposed to load up different movies or do something different, but the wrapper is rather horribly corrupting the memory state of the program. I should have been asleep, oh, 4 hours ago at the latest, so I do not have time to diagnose it now, but for later I would *love* it if you could give me any info on your wrapper file and what else it does and loads so that tracing through it will be easier later, hopefully looking into what it will be overwriting in memory because it is apparently overwriting something wrong, possible messing up the dynamic link table of the program (since that is where the program jumps into invalid memory is from the dynamic link table, can definitely tell A2 was compiled by an old compiler looking at that assembly).
If you need any help with code of such things, I have been doing this for years and the past week is the first time I have had free time in near a year, it may not last too long though, so if there is anything I can help with, feel free to ask.
Also, I noticed something odd, the splash screen that A2 pops up for a second while it first loads, is not a normal A2 picture, in fact it is the handle of another program that is currently running on my system, meaning that I bet the handle for it is also corrupted and it is by random chance picking a handle that is actually used by another image on the system (rather then like a file handle or a mutex handle or, you know, a handle that is not defined), I plan to look into that as well since it may also indicate where something is getting corrupted.
Either way, yes, the d3d8.dll hook, something it is passing off is royally screwing up memory, will try to figure out more later, for now, sleep, have work in a few hours...
posted on May 29th, 2009, 2:43 pm
Last edited by OvermindDL1 on May 29th, 2009, 4:01 pm, edited 1 time in total.
posted on May 29th, 2009, 3:28 pm
Last edited by DOCa Cola on May 29th, 2009, 3:33 pm, edited 1 time in total.
posted on May 29th, 2009, 4:10 pm
Last edited by OvermindDL1 on May 29th, 2009, 4:22 pm, edited 1 time in total.
Sorry, apparently this forum software does not alert when someone makes a new post while you are doing an edit, so... I added an edit above in my post right before your last one.
So from what you said, the part of the memory that I have to keep fixing each time is the loadlibrary function itself, do you overwrite its code, or at least the jump table location of it? If so that would explain why it is rather horribly corrupted.
Changing the exe of A2 itself to link in another dll and call a function from it to hook 'stuff' only involves adding about 12 or so lines so machine code to it, and I have done that exact thing to other programs many times in the past, would it not be a lot easier, not to mention safer and more correct, to do that instead, or perhaps wrapping a dll that A2 itself uses and nothing else does (seems to be a nice large amount of libraries in that directory after all, the bink library looks like a perfect candidate, just create your own library main function to do what you need, maybe hook a function or two, and forward all other references from the normal bink library into your own so everything is transparently done?).
But yea, this hook library of yours seems to link in a huge amount of stuff, I am wondering what you use it all for?
And what is this TThemeNexus pervading this library, is it a whole new UI system for A2 or something (I have not yet even seen screenshots of this latest version), if so that sounds like a ton of work, I am quite interested to see how it looks, themes based on the race you pick or something?
EDIT1: This is also fascinating. I am placing breakpoints all inside of this hook dll of yours the library main function, the only exposed function I see, etc... None of them are being hit, however I can get into it just fine if I place a breakpoint in a system dll that your hook dll calls and follow it back down the callstack back into your library, this is rather funky weird...
EDIT2: Also, the MSDN documentation on calling IsAppThemed:
And guess what your hook is doing, calling it *during* the library main function. Guess what my OS is, Windows XP. Guess what is happening, yea, exactly, please fix that, or better yet remove it, there is never a need to call that function (or anything else in UxTheme).
The proper way to theme your windows is to add a manifest file that states so, the manifest needs to be at resource ID 24 as I recall, *NEVER* use UxTheme directly... At the very least, do not call that function during Library load time, just like MSDN tells you not to.
So from what you said, the part of the memory that I have to keep fixing each time is the loadlibrary function itself, do you overwrite its code, or at least the jump table location of it? If so that would explain why it is rather horribly corrupted.
Changing the exe of A2 itself to link in another dll and call a function from it to hook 'stuff' only involves adding about 12 or so lines so machine code to it, and I have done that exact thing to other programs many times in the past, would it not be a lot easier, not to mention safer and more correct, to do that instead, or perhaps wrapping a dll that A2 itself uses and nothing else does (seems to be a nice large amount of libraries in that directory after all, the bink library looks like a perfect candidate, just create your own library main function to do what you need, maybe hook a function or two, and forward all other references from the normal bink library into your own so everything is transparently done?).
But yea, this hook library of yours seems to link in a huge amount of stuff, I am wondering what you use it all for?
And what is this TThemeNexus pervading this library, is it a whole new UI system for A2 or something (I have not yet even seen screenshots of this latest version), if so that sounds like a ton of work, I am quite interested to see how it looks, themes based on the race you pick or something?
EDIT1: This is also fascinating. I am placing breakpoints all inside of this hook dll of yours the library main function, the only exposed function I see, etc... None of them are being hit, however I can get into it just fine if I place a breakpoint in a system dll that your hook dll calls and follow it back down the callstack back into your library, this is rather funky weird...
EDIT2: Also, the MSDN documentation on calling IsAppThemed:
Do not call this function during DllMain or global objects contructors. This may cause invalid return values in Windows Vista and may cause Microsoft Windows XP to become unstable.
And guess what your hook is doing, calling it *during* the library main function. Guess what my OS is, Windows XP. Guess what is happening, yea, exactly, please fix that, or better yet remove it, there is never a need to call that function (or anything else in UxTheme).
The proper way to theme your windows is to add a manifest file that states so, the manifest needs to be at resource ID 24 as I recall, *NEVER* use UxTheme directly... At the very least, do not call that function during Library load time, just like MSDN tells you not to.
posted on May 29th, 2009, 4:29 pm
Last edited by DOCa Cola on May 29th, 2009, 4:33 pm, edited 1 time in total.
The fohook uses delphis vlc which is quite heavy fot the ui stuff. A 3rd party component seems to cause the uxtheme.dll issue (gr32 for delphi)
Sure the bink would ne a great candidate, but the guys from a2f files didn't want me to touch any executable files
Edit: i think you even told me that 'the dll is heavy' stuff the last time btw i really like it when you have issues with fo and come to the forums 
Sure the bink would ne a great candidate, but the guys from a2f files didn't want me to touch any executable files
Edit: i think you even told me that 'the dll is heavy' stuff the last time
btw i really like it when you have issues with fo and come to the forums posted on May 30th, 2009, 12:37 am
Ah, I remember now that you use Delphi, you mentioned that last time. It is still one of the only language I have never touched (still meant to look at it sometime, I am a heavy C/C++ person primarily). I guess you should edit that third-party component a touch because what they are doing, Microsoft says *DO*NOT*DO*, since what they are doing can, at worst, cause system instability on Windows XP platforms, and even cause issues with Vista.
That function should never really need to be called though, if you want to get the windows theme information (why on earth would you need to?!?) then accessing a certain registry key gives you more info like if it is enabled or not (as that function is supposed to do) and also *what* theme is being used.
What do you need the UI stuff for, are you embedding it into A2 as a new interface? I had been planning to create a texture wrapper for wxWidgets. wxWidgets universal mode does not use system native widgets, meaning you can create your own interface for it, so it would actually be quite easy to embed a wxWidgets gui into a 3d app, seemed like it would always be a fun challenge that no one else has done yet.
You could always patch the A2 executable, or anything else. That means you do not need to package the existing game exe with your distributable, but you still get much more stable prospects. I could help with that if necessary.
Heh, you like it when I come here with all these issues? Sounds like you might be like me, I generally go for the most difficult projects I can find, such as finding and fixing bugs by digging into disassembly (honestly, how many people do you know can even read that stuff as well as actually like doing so ).
I am still curious, what is everything the hook dll does?
That function should never really need to be called though, if you want to get the windows theme information (why on earth would you need to?!?) then accessing a certain registry key gives you more info like if it is enabled or not (as that function is supposed to do) and also *what* theme is being used.
What do you need the UI stuff for, are you embedding it into A2 as a new interface? I had been planning to create a texture wrapper for wxWidgets. wxWidgets universal mode does not use system native widgets, meaning you can create your own interface for it, so it would actually be quite easy to embed a wxWidgets gui into a 3d app, seemed like it would always be a fun challenge that no one else has done yet.
You could always patch the A2 executable, or anything else. That means you do not need to package the existing game exe with your distributable, but you still get much more stable prospects. I could help with that if necessary.
Heh, you like it when I come here with all these issues? Sounds like you might be like me, I generally go for the most difficult projects I can find, such as finding and fixing bugs by digging into disassembly (honestly, how many people do you know can even read that stuff as well as actually like doing so
).I am still curious, what is everything the hook dll does?
posted on May 30th, 2009, 12:50 am
OvermindDL1 wrote:...and even cause issues with Vista...
What doesn't?
posted on May 30th, 2009, 12:53 am
Adm. Zaxxon wrote:What doesn't?
Heh, true.
Hmm, I wonder if Fleet Ops would run in Wine in Ubuntu... Might give that a try sometime...
posted on May 30th, 2009, 5:51 am
Last edited by OvermindDL1 on May 30th, 2009, 9:35 am, edited 1 time in total.
posted on May 30th, 2009, 9:47 am
Last edited by DOCa Cola on June 1st, 2009, 12:12 pm, edited 1 time in total.
WOOT! I have been able to launch it! At the very least I get to the main menu, have not yet tried to play it.
First of all, the PATH environment variable, if too long, still causes it to crash (with an out of memory error, what the frick?).
Second, I fixed the bug with the UXTheme.dll problem, and a couple other minor things I ran into. Also, I altered your CRC code a bit so my edits are accepted (that was fun...).
Now, to load it up (with a bat file that changed the environment path variable so it does not insta-die on load, that really needs to be fixed, maybe I will add that to your dll, I found your 'winmain' overloader, a couple long jumps and a couple hundred bytes free of executable area, (and from my profiling there is a huge amount of code in that library that is not ever run, whatever compiler you used, you either need to change your options, or you really need to get a new compiler because dang, that is bad) and I could have it perma-fix that bug too.
Depending on how the game plays, I will report my results shortly. Also, I love the new menu, never did like all that corner stuff that the normal one did, the new one also feels faster.
EDIT: Yep, just slaughtered the Federation and Klingon as Borg, works fine now. I have attached the altered dll that fixed the uxtheme error and so forth, might let some other people get working without needing to reinstall windows or whatever they have been doing. The attached file is a standard 7zip file, extractable by most uncompressing programs (since the dll by itself is too big to be an attachment without compressing). If Doca Cola does not want this fixed one available, well, he can remove it from my post, he can also compare the machine code to see what I changed (like 4 lines of code I think? I did only the minimal edits necessary to get it operational).
DOCaEdit: Removed the attached file, please get the test patch from this thread: Star Trek Armada II: Fleet Operations - 3.0.7 pre-release - test patch
First of all, the PATH environment variable, if too long, still causes it to crash (with an out of memory error, what the frick?).
Second, I fixed the bug with the UXTheme.dll problem, and a couple other minor things I ran into. Also, I altered your CRC code a bit so my edits are accepted (that was fun...).
Now, to load it up (with a bat file that changed the environment path variable so it does not insta-die on load, that really needs to be fixed, maybe I will add that to your dll, I found your 'winmain' overloader, a couple long jumps and a couple hundred bytes free of executable area, (and from my profiling there is a huge amount of code in that library that is not ever run, whatever compiler you used, you either need to change your options, or you really need to get a new compiler because dang, that is bad
) and I could have it perma-fix that bug too.Depending on how the game plays, I will report my results shortly. Also, I love the new menu, never did like all that corner stuff that the normal one did, the new one also feels faster.
EDIT: Yep, just slaughtered the Federation and Klingon as Borg, works fine now. I have attached the altered dll that fixed the uxtheme error and so forth, might let some other people get working without needing to reinstall windows or whatever they have been doing. The attached file is a standard 7zip file, extractable by most uncompressing programs (since the dll by itself is too big to be an attachment without compressing). If Doca Cola does not want this fixed one available, well, he can remove it from my post, he can also compare the machine code to see what I changed (like 4 lines of code I think? I did only the minimal edits necessary to get it operational).
DOCaEdit: Removed the attached file, please get the test patch from this thread: Star Trek Armada II: Fleet Operations - 3.0.7 pre-release - test patch
posted on May 31st, 2009, 6:36 pm
the failing code is actually not mine, as is the crash dialog box or crc check. the jedi stuff and so on are 3rd party components like checkboxes or buttons and so on. the delphi compiler seems to link in a lot of code that is not used or only used in cases that can never occur when these components are used. i am glad that i didn't have to develop that ui with just through api calls. i can not set many options on the compiler btw - but this is usually no problem either as that only increases the size of the executable which shouldn't be a problem nowadays.
as far as i know the crash dialog box want's to open your mail program through a call to the windows mapi interface. usually should be working. i have no access to the actual code of the exception box, it's pre-compiled, which makes the dll heavier in disk space either.
thanks for your time looking into this issue. i'll probably take a look into your modified dll tomorrow.
i can not set many options on the compiler btw - but this is usually no problem either as that only increases the size of the executable which shouldn't be a problem nowadays.as far as i know the crash dialog box want's to open your mail program through a call to the windows mapi interface. usually should be working. i have no access to the actual code of the exception box, it's pre-compiled, which makes the dll heavier in disk space either.
thanks for your time looking into this issue. i'll probably take a look into your modified dll tomorrow.
posted on June 1st, 2009, 1:00 am
1, 2
Who is online
Users browsing this forum: No registered users and 21 guests