Hello everyone,
I am to trying to use Windbg (64-bit). I have Windbg running, but I don't know how to provide it with debug symbols. I'm assembling with ml64.exe and linking with polink. What switches do I need to set? I've exhausted my ability to Google on this one.
Thanks,
Mark Allyn
I think aw27 knows a lot of windbg. But if it's too complicated to start with, you can try x64dbg instead. ;)
Do you mean using the Microsoft symbols? That uses an environment variable
Quote_NT_SYMBOL_PATH=srv*c:\symbols*http://msdl.microsoft.com/download/symbols
Windbg should load the pdb file from the program directory automatically.
Hi markallyn,
I use x64dbg. It's a very good tool.
Quote from: felipe on October 01, 2017, 03:29:42 PM
I think aw27 knows a lot of windbg.
Nobody knows a lot about Windbg, it has infinite possibilities. :icon_rolleyes:
The most import first step is to get a decent Workspace. A suggestion is this one (http://www.zachburlingame.com/2011/12/customizing-your-windbg-workspace-and-color-scheme/).
Thanks all of you for trying to help-
Sinsi: How do I get a PDB file from Polink? There seems to be no /PDB switch.
Vortex and Felipe: I've tried to install x64dbg, but when I unzip to the window where I am supposed to be able to launch x64, nothing happens when I click on that button. Can you suggest what I should do?
Thanks again for your help.
Mark Allyn
Hello Sinsi,
Also, I am using Polink because when I try to generate a PDB file from link.exe the linker kicks out the following fatal error message: "incorrect MSPD100.DLL version: recheck installation of this product". There is a dll by that name in the directory with the link executable, by the way.
Mark
Sorry, i have installed (but don't remember, maybe there is nothing to install) x32dbg and x64dbg some months ago and can't remember right now how i did it. Also i don't have the time now for doing it again. Try to check the debbuger page for instructions. :idea:
Hi mark,
x64dbg is a portable application. Downloaded today the latest version snapshot_2017-09-12_00-45.zip and extracted the content to the folder C:\x64dbg
Executing the 64-bit debugger :
C:\x64dbg\release\x64\x64dbg.exe
Quote from: Vortex on October 02, 2017, 05:18:56 AM
Hi mark,
x64dbg is a portable application. Downloaded today the latest version snapshot_2017-09-12_00-45.zip and extracted the content to the folder C:\x64dbg
Executing the 64-bit debugger :
C:\x64dbg\release\x64\x64dbg.exe
snapshot_2017-09-30_14-39.zip ::)
Here, the latest release dates September 12 ( snapshot_2017-09-12_00-45.zip ) :
https://sourceforge.net/projects/x64dbg/files/snapshots/
Checking github, the latest release is snapshot_2017-10-01_14-37.zip :
https://github.com/x64dbg/x64dbg/releases
The x64dbg design was ruthlessly stolen from Olly, with one important difference: To make x64dbg work properly, you need to set SkipInt3Stepping=1 in x64dbg.ini; otherwise it will get stuck at your int 3.
Hi Mark,
I don't use polink but mslink uses two switches, /debug /debugtype:coff
Apparently, /Zi /Zf for the assembler and /debug for the linker are enough.
I've installed the latest x64dbg now, and it works most of the time (on my Win7-64 machine, x64dbg often crashes on exit; it has problems saving its database); here is a testbed, paste in RichMasm and hit F6.
include \Masm32\MasmBasic\Res\JBasic.inc ; install (http://masm32.com/board/index.php?topic=94.0)
Init ; OPT_64 1 ; in RichMasm, hit F6 to launch \Masm32\x64Dbg\release\x64\x64dbg.exe
int 3
PrintLine Chr$("This code was assembled with ", @AsmUsed$(1), " in ", jbit$, "-bit format")
MsgBox 0, "Wow, it works!!!!", "Hi", MB_OK or MB_SETFOREGROUND
EndOfCode
Hello everyone,
Thanks to all of you for helping out on this. Here is current status.
After struggling with the x64dbg zip file I finally--though I can't quite figure out how--managed to install it. It seems to run OK. Question: what switches do I need in ml64.exe and polink in order to get usable debug information? Polink objects strongly to using the /DEBUG switch and complains about codeview symbols being present in the .obj file. What's with that? It complains even when I don't use /Zi and /Zd in the assemble step. Perhaps a different linker?
Sinsi: Someday when I've grown up I will try again to do Windbg, but until I can figure out what's going on with this MSPDB100.DLL that seems to be a dead end. This problem, as mentioned earlier, is why I turned to Polink.
jj2007: I am hunting for x64dbg.ini. Haven't found it yet.
I'm still not there yet, but pluggin' away.
Mark
Quote from: markallyn on October 02, 2017, 11:28:19 AM
jj2007: I am hunting for x64dbg.ini. Haven't found it yet.
\Masm32\x64Dbg\release\x64\x64dbg.ini
Hello sinsi,
The link.exe version I'm running doesn't have a /DEBUGTYPE switch. Has only /DEBUG. I'm assembling with ml64.exe with /Zi and /Zf options. When I link I use the command line: "link.exe /DEBUG /SUBSYSTEM:console /ENTRY:main /OUT:mystart.exe mystart.obj". Then I get the error message that MSPDB100.DLL is the wrong version.
Mark
JJ:
Thank you. Very kind. I'll let you know what happened.
Mark
Quote from: markallyn on October 03, 2017, 12:07:24 AM
Then I get the error message that MSPDB100.DLL is the wrong version.
Each link.exe requires a matched version of MSPDB in the same folder (or in system32).
Were you using the link.exe from VS2017 you would need mspdb140.dll in the same folder.
Sounds complicated?
I use the microsoft linker to output pdb files for debugging with x64dbg:
LINK.EXE /SUBSYSTEM:WINDOWS /DEBUG /DEBUGTYPE:CV /PDB
and also the /Zi /Zd switches when assembling to help with showing other debug info
AW27 and Fearless,
AW27: I have mspd100.dll and mspd140.dll in the same folder along with link.exe. Moreover, this folder is reachable via the PATH environmental variable.
Fearless: Thanks for the info on the assembler\linker switches. I'll try them forthwith.
Thanks to both of you for helping me with this blasted issue.
Markl
Hi Fearless,
Would love to report that your link.exe switches solved my problem, but they didn't. Still getting the cryptic message "incorrect MSPDB100.DLL version; recheck installation of this product".
Regards,
Mark
Here is my stuff im using for the linker, from one of the vs studio installations (v12.x in the file manifests):
https://www.dropbox.com/s/wozllpfru8cbttf/vs2012tools.zip?dl=0
probably will require the visual c runtime for 12.x (MSVCR120.dll) installed in your system somewhere
I have all those files in my masm\bin folder
OK, make sure they are the same bitness than link.exe
aw27,
I checked for bitness and came away completely confused by what I saw. All three of ml64.exe, link.exe, and mspdb100.dll appear to be 32-bit PE files. I say this because that is what I got from dumpbin /HEADERS and also from looking at the symbol following PE in the binary files using notepad.
Perhaps you can explain this. I don't understand how ml64.exe could assemble code which uses 64 bit registers without itself being a 64-bit program.
Mark
Quote from: markallyn on October 04, 2017, 12:34:39 AMI don't understand how ml64.exe could assemble code which uses 64 bit registers without itself being a 64-bit program.
The translation of human-readable source code into machine code has nothing to do with the "bitness" of the assembler. You could generate 64-bit machine code with a 16-bit QBasic program.
Quote from: markallyn on October 04, 2017, 12:34:39 AM
I checked for bitness and came away completely confused by what I saw. All three of ml64.exe, link.exe, and mspdb100.dll appear to be 32-bit PE files. I say this because that is what I got from dumpbin /HEADERS and also from looking at the symbol following PE in the binary files using notepad.
You are correct. Probably you need to run VCVARS64.BAT (or continue investigating).
If this helps, I can advance that this works for VS 2017, but paths are a bit long:
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64\ml64" -c -Zp8 /Zd test64.asm
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64\link" /SUBSYSTEM:console /ENTRY:Start /DEBUG:FULL test64.obj
Alternatively, if you copy following files from C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64
to your \masm32\bin directory it will work as well:
link.exe
msobj140.dll
mspdb140.dll
mspdbcore.dll
For Visual Studio 2010, probably you need to copy some more .DLLs in addition to mspdb100.dll
JJ2007 and aw27,
Thanks for responding.
JJ: I understand your point, I believe, but I was surprised that ml64.exe wasn't itself (apparently) a 64 bit program. I know JWOW is there to handle 32-bit code, but still, it seems surprising.
aw27. At the moment, I don't have Visual Studio running. I have tried to install Visual Studio Express, but so far I haven't been successful.
In any case, ml64.exe, link..exe, and mspdb100.dll are all in the same bit format.
I guess I'm going to have to renew my efforts to get VS Xpress working.
Regards,
Mark
Quote from: markallyn on October 04, 2017, 03:48:01 AM
aw27. At the moment, I don't have Visual Studio running. I have tried to install Visual Studio Express, but so far I haven't been successful.
VS Express editions are crippled, it is better Community Editions which are almost the same as Pro.
Mark,
JJ's comment is right, when you are building a binary file you are writing BYTE data to a disk file and it could be done with anything that can write BYTE Data to a file. There is no immediate reason to build compilers, linker, assembler and the like as 64 bit binaries as there is no real advantage in doing so and it would involve complete rewrites of these tools from scratch which is a massively complex task. Under a 64 bit version of Windows (win7 and up) you can get close to 3.5 gig of memory and you can build really big files that way so 64 bit does not provide any immediate advantage here.
What I do with Win 10 64 bit is download the enterprise version, get all of the BIN binaries from it along with the include files and libraries and then uninstall it as I don't want a ton of crap buried on my boot drive. For the earlier 64 bit OS versions, you do the same thing with their OS specific versions.
Hutch and JJ-
Thanks for the clarification.
OK, here's where I am now. I downloaded and installed all day yesterday VS 2015 Express. Fortunately, I had to mow a great deal of lawn and so I passed the time away ...
Everything proceeded well. I found the necessary binaries in the /VC/amd64/bin folder and thought I was in the clear. But, not so!. Turns out that I needed to be using the "Developer Command Prompt for VS2015" in order to assemble and link properly. I don't understand why the ordinary Command Prompt doesn't do the job, but so be it. It can run ml64.exe, but not link.
Anyway, I now have a functioning cl.exe as a useful byproduct of the download/install.
Thanks, gentlemen, for your patience.
Now I have to tackle how to write leaf and frame functions. Still tryimg to understand how to deal with rsp.
Regards,
Mark
Mark,
Generally you leave the stack pointer alone, you have enough registers to not have to worry about it.
Look in the directory above bin to get the required "linkui.dll". It needs to be put in a directory called "1033" directly off the bin64 directory.
This is what I have in my Win10 version in the 1033 directory.
atlprovui.dll
bscmakeui.dll
clui.dll
cvtresui.dll
linkui.dll
LocalESPCui.dll
lst.txt
mspdbcmfui.dll
mspft140ui.dll
nmakeui.dll
pgort140ui.dll
pgoui.dll
Look around the folders in vc to find the ones you need.
Hutch,
Thanks for the info about the 1033 directory. I will investigate.
As for wiggling the rsp, you are most certainly right that the 4 registers are sufficient most of the time. Unfortunately, I have this awful habit of investigating every nook and cranny, so not really understanding leaf and frame calls bothers me a lot.
I investigated your "invoke" macro to see how you were managing the rsp since it looks like your invoke can tell from the function PROTO how to set rsp in the caller. I couldn't follow the macro code.
A couple of good examples of "non-invoked" calls to a leaf and the leaf code would be very helpful. Same with frame functions.
Thanks very much for all of your tutoring, and others such as aw27 and JJ and Fearless among others. Your generosity gives me hope for humanity.
Mark
Mark
Mark,
The distinction between a stack frame as against no stack frame is the one you are looking for here. A leaf procedure that only uses mnemonics can usually be written without a stack frame whereas a procedure that calls other procedures or locals usually has a stack frame. The choice here is to either use a stack frame of not use one. There are a couple of macros that control this which are simple enough to use.
NOSTACKFRAME ; turn the stack frame off
STACKFRAME ; turn it back on again.
You put these before and after a procedure that does not have a stack frame.
Now with the integer registers, you can modify rax rcx rdx r8 r9 r10 r11, the rest need to be protected so that they are the same on procedure exit and with MASM, avoid using push/pop as the preferred method is to use local variables to save and restore registers.
64 bit MASM does not use prototypes which is a blessing in that you don't have to write them but it means you must get the argument count right.
Now with calling procedures, you can manually call simple procedures with up to 4 arguments by writing the arguments in the order of rcx rdx r8 & r9 and using the CALL mnemonic but with a higher argument count, you are better off to use the "invoke" technique as arguments 5 and up are written to the stack and can be messy and complicated to do manually. This is due to the structure of the Microsoft FASTCALL calling convention.
LATER : Something I should have added, a good starter debugger/disassembler is called ArkDasm http://www.arkdasm.com/ and it was very useful to me when I first started to work on 64 bit MASM. There are more complex and more powerful ones around but this one is simple and its dis-assembler will show you much of what you are looking for.
Hutch,
Played with STACKFRAME. Now I understand where the ENTER 80h,0 and SUB rsp, 60 come from. Big Help. Question: why 80h for enter and sub 60? Seems kind of arbitrary, without knowing more than I do.
Yes, I've been using Arkdasm and also x64dbg. Nice programs!
Still searching for how to manipulate rsp--either with or without frame.
Mark
Mark,
Have a read of the masm64 help file, it explains how and why the stackframe when used is constructed in this manner. Alignment is important, mess that up and the app will not run and will not tell you why. You are dealing with the Microsoft FASTCALL calling convention which use 4 registers for the first 4 arguments and any more are written to the stack.
For reference on using ENTER, you will need to have a good read of the Intel manual for both ENTER and LEAVE. The question you have asked does not have a simple answer, FASTCALL in 64 bit is a tangled mess that you must get right and that is why it is presented as a macro to avoid the complexity and inherent mess of its design. The macro that "invoke" calls is just as messy and complicated as it has to provide the arguments in the right order and format.
As far as directly manipulating RSP, tread with caution here as the pitfalls are many and the uses are few. The problem with getting any alignment wrong is that of the app will not run and just disappears with no explanation of why.
Hutch-
I looked in help64, but couldn't find a reference to stackframe.
I downloaded the entire x86 IA32 4 volume set you referenced. Should be very helpful in future.
Is that a sly reference to Woody Guthrie's old great song "Dark as a Dungeon" in the next to last line? The Guthrie bit goes like this: "It's dark as a dungeon and damp as the dew, where the dangers are many and the pleasures are few". Can't be a coincidence.
Regards,
Mark
Design Criteria
Calling Convention
How the Win 64 calling convention works.
Stack frame reference
How the MASM64 stackframe works. <<< This one.
Call automation
How to use invoke and similar notation.
The rcall macro
A low overhead alternative to invoke for 4 arguments or less.
Hutch,
Thanks for the info. This whole business is very messy, as you say. I don't like messy.
Mark
Quote from: markallyn on October 06, 2017, 01:43:47 PM
I don't like messy.
I prefer Ronaldo to messi as well :t
Quote from: markallyn on October 06, 2017, 01:43:47 PM
I don't like messy.
Quote from: aw27 on October 06, 2017, 05:46:51 PM
I prefer Ronaldo to messi as well :t
Don't worry! We are almost out of next Mundial :eusa_snooty:
Quote from: HSE on October 07, 2017, 12:33:35 AM
Don't worry! We are almost out of next Mundial :eusa_snooty:
The World is not fair. :shock: