Parser on Vista/64/RTM

Status
Not open for further replies.
M

Mikeal

New Member
I am assuming the source will not be made available. I am having problems with it on Vista/64/RTM Ultimate and I am not sure anyone else with source access is going to have the same type of environment to test with at this time.

Would it be possible to get a filemon:
http://www.microsoft.com/technet/sysinternals/utilities/filemon.mspx

run on XP/32 or XP/64 so I could compare results and see if I can find out anything that helps us?

~ Mikeal
 
How familiar are you with software development / debugging techniques? If you can make a crash dump file of your FFXI process address space (including a dump of the heap) I can probably make it work by looking at that. I could probably walk you through the necessary steps if you don't know how to do it already.

Necessary tools required for you to do this are either a) Visual Studio 2005 (Express Edition is free, but not sure if Express Edition allows you to make crash dumps. other editions aren't free), or WinDBG (free).
 
Kalia said:
How familiar are you with software development / debugging techniques? If you can make a crash dump file of your FFXI process address space (including a dump of the heap) I can probably make it work by looking at that. I could probably walk you through the necessary steps if you don't know how to do it already.

Necessary tools required for you to do this are either a) Visual Studio 2005 (Express Edition is free, but not sure if Express Edition allows you to make crash dumps. other editions aren't free), or WinDBG (free).
Click to expand...

95% of all the programming I do is web based.

I do have Visual Studio 2005 though. Not sure how to make a dump, but I can probably google it eh?

~ Mikeal
 
Here's what you do (you don't need the parser running at all).

1) Open Visual Studio 2005.
2) Launch FFXI and log into your character
3) Type a few lines of text into the /say window from your mog house.
4) In VS2005 go to Debug->Attach to Process.
5) In the dialog that pops up, choose pol.exe and click the Attach button.

At this point FFXI will still be running and you can do stuff in game. After the next step it will be hung. This is normal.

6) Go to Debug->Break All and press OK on the dialog that pops up.
7) Go to Debug->Save Dump As
8) Choose Minidump with Heap (*.dmp) from the file filter combo box.
9) Choose a name for this file and press Save.

After this it will take a few minutes for Visual Studio to become responsive again. You can verify that something is actually happening though by finding that file in Windows Explorer, and each time you hit Refresh in Explorer the file will be a little bit bigger than it was before. Afte Visual Studio finally becomes responsive again, hit F5 to make FFXI become responsive again. FFXI will have timed out by now, so it will kick you back to the login screen. No worries, just log back in.

You'll need a place to host that .dmp file so I can download it. It's going to be large, probably more than 600MB.

Edit: I can provide you an FTP to upload the .dmp file to if necessary.
 
Vista has something called ASLR (Address space layout randomization). Obviously without having a 64 bit box to test on, I can't confirm that this is the problem, but could you try to disable it and see if the parser works? It's probably accessible through Control Panel somewhere, I imagine it's going to be somewhat hidden since they don't really want people disabling this (it makes certain security vulnerabilities much more difficult for hackers to exploit). I'm still looking into the dump file btw.
 
Well, according to the dump file memory layout is exactly as I expect it to be. Not surprising in that I knew FFXI had to be running in 32-bit compat mode. Surprising in that it should work if that's the case >.> What's in your debug.log file when you click Start New Parse? It should be in same directory as parser.


Edit: I think I may have solved the problem, but the source code is at home so I'll try to make a new build when I get home from work and keep you posted.
 
Last edited:
Kalia said:
Well, according to the dump file memory layout is exactly as I expect it to be. Not surprising in that I knew FFXI had to be running in 32-bit compat mode. Surprising in that it should work if that's the case >.> What's in your debug.log file when you click Start New Parse? It should be in same directory as parser.


Edit: I think I may have solved the problem, but the source code is at home so I'll try to make a new build when I get home from work and keep you posted.
Click to expand...


Alright, I am stuck at work as well and the girlfriend is going to drag me all over town after work... So ill probably check/load tonight around 9-10cst if you've had time to compile by then.

~ Mikeal
 
Ok, the 64-bit issue is officially fixed :) You asked in PM how I fixed it, but I'll post it here since I know at least a few people who are gonna download this thing are nerds like me. In fact what I did was the simplest possible thing you can do. Nothing!

Lemme take a step back though. 64-bit Operating Systems (and CPUs) have a special mode called WOW64. And no, I don't mean World of Warcraft. A lot of people think that just because you get a 64-bit OS and a 64-bit CPU all your stuff is going to automatically be twice as awesome and run twice as fast. Unfortunately its' not true though. The code that executes on the CPU has to be specifically built for 64-bit platform. You can use the same source code for producing native 32-bit and native 64-bit code, but the compiler has to choose one or the other. In the case of native code, this (usually) means deciding at compile time which CPU you're going to target, and locking yourself into that decision forever.

When an application does not have that compiler switch flipped, it's just a normal 32-bit application. In this case, WOW64 kicks in. When WOW64 is active for an application, you are pretty much not seeing any performance gains at all over a 32-bit version of the same processor (this isn't totally true, but it's pretty close). In fact, it's equivalent to a 32-bit app running on a 32-bit OS in every possible respect. The address space, the pointer sizes, everything is exactly the same.

FFXI is a 32-bit application. It didn't have that compiler switch flipped when it was built. So when I read the memory from the process, my code must be exactly the same as it is for the 32-bit OS case in every respect. Even though it's a 64-bit OS and a 64-bit CPU, since FFXI is a 32-bit application I must treat it as one. That was my fundamental flaw.

When you're compiling native code (e.g. C++) this is a non issue because if you want a 64-bit build you have to specifically tell the compiler to produce 64-bit code. If you choose the "Any CPU" compiler option for native code it just goes to the lowest common denominator (32-bit mode) and produces 32-bit code. In .NET it's different, because .NET is a virtual runtime environment. You're not producing native code in the first place, you're producing something that is turned into native code when you run the program. So in .NET, if you choose the "Any CPU" option it behaves differently. Since the code isn't compiled until you run it, the runtime environment says "oh hey, this is a 64-bit OS, i'll produce 64-bit code". Now I'm using 64-bit code to attempt to read from the memory of FFXI, which treats FFXI as a 64-bit address space (which it clearly isn't), and everything goes to hell.

The solution was to flip a compiler switch when I build the parser. Instead of "Any CPU", I just changed it to "x86".
 
Last edited:
Status
Not open for further replies.
Back
Top