I am using x64Dbg with 64-bit code, and it's nugging me because while I do see symbols for WinAPI calls, I don't see any for my own procedures. Example:
include \Masm32\MasmBasic\Res\JBasic.inc ; ## builds in 32- or 64-bit mode with UAsm, ML, AsmC ##
usedeb=1 ; use/don't use the deb macro
.code
SayHi proc arg1:SIZE_P
jinvoke MessageBox, 0, rcx, Chr$("Hi"), MB_OK or MB_SETFOREGROUND
ret
SayHi endp
Init ; OPT_64 1 ; put 0 for 32 bit, 1 for 64 bit assembly
; int 3
jinvoke SayHi, Chr$("Wow, it works!!!!")
EndOfCode
OPT_Symbols 1 ; RichMasm option: A: /Zi /Zf, L: /debug
Disassembly:
0000000140001000 | 55 | push rbp |
0000000140001001 | 48:8D6C24 F0 | lea rbp,qword ptr [rsp-10] | [rsp-10]:"ÃÌÌÌÌÌMessageBoxA"
0000000140001006 | 8365 00 00 | and dword ptr [rbp],0 |
000000014000100A | 48:83C5 04 | add rbp,4 |
000000014000100E | 48:3BEC | cmp rbp,rsp |
0000000140001011 | 78 F3 | js 140001006 |
0000000140001013 | 48:81EC 90000000 | sub rsp,90 |
000000014000101A | 41:B9 00000100 | mov r9d,10000 | r9d:" Á¾w"
0000000140001020 | 4C:8D05 F11F0000 | lea r8,qword ptr [140003018] |
0000000140001027 | 48:8BD1 | mov rdx,rcx |
000000014000102A | 33C9 | xor ecx,ecx |
000000014000102C | FF15 5E210000 | call qword ptr [<&MessageBoxA>] |
0000000140001032 | C9 | leave |
0000000140001033 | C3 | ret |
0000000140001034 | C8 8000 00 | enter 80,0 |
0000000140001038 | E8 2A000000 | call 140001067 | own proc: no symbols!
000000014000103D | 33C9 | xor ecx,ecx |
000000014000103F | FF15 53210000 | call qword ptr [<&SetLastError>] |
0000000140001045 | FF15 55210000 | call qword ptr [<&GetProcessHeap> |
000000014000104B | 48:8905 1E210000 | mov qword ptr [140003170],rax |
0000000140001052 | CC | int3 |
0000000140001053 | 48:8D0D C11F0000 | lea rcx,qword ptr [14000301B] | 000000014000301B:"Wow, it works!!!!"
000000014000105A | E8 A1FFFFFF | call 140001000 | own proc: no symbols!
000000014000105F | 33C9 | xor ecx,ecx |
0000000140001061 | FF15 41210000 | call qword ptr [<&RtlExitUserProc |
0000000140001067 | 48:8D0D BF1F0000 | lea rcx,qword ptr [14000302D] | 000000014000302D:"user32"
000000014000106E | 48:8D15 0B210000 | lea rdx,qword ptr [140003180] | 0000000140003180:&"MZ"
0000000140001075 | E8 21000000 | call 14000109B | own proc: no symbols!
000000014000107A | C3 | ret |
Question: is that a "feature" of X64Dbg only, do other debuggers behave the same, is there any option that I may have overlooked?
I found a workaround, see attached executables (both have an int 3), but it would be easier to just use an option... :cool:
Quote from: jj2007 on April 03, 2021, 07:51:41 PM
I am using x64Dbg with 64-bit code, and it's nugging me because while I do see symbols for WinAPI calls, I don't see any for my own procedures. Example:
include \Masm32\MasmBasic\Res\JBasic.inc ; ## builds in 32- or 64-bit mode with UAsm, ML, AsmC ##
usedeb=1 ; use/don't use the deb macro
.code
SayHi proc arg1:SIZE_P
jinvoke MessageBox, 0, rcx, Chr$("Hi"), MB_OK or MB_SETFOREGROUND
ret
SayHi endp
Init ; OPT_64 1 ; put 0 for 32 bit, 1 for 64 bit assembly
; int 3
jinvoke SayHi, Chr$("Wow, it works!!!!")
EndOfCode
OPT_Symbols 1 ; RichMasm option: A: /Zi /Zf, L: /debug
Disassembly:
0000000140001000 | 55 | push rbp |
0000000140001001 | 48:8D6C24 F0 | lea rbp,qword ptr [rsp-10] | [rsp-10]:"ÃÌÌÌÌÌMessageBoxA"
0000000140001006 | 8365 00 00 | and dword ptr [rbp],0 |
000000014000100A | 48:83C5 04 | add rbp,4 |
000000014000100E | 48:3BEC | cmp rbp,rsp |
0000000140001011 | 78 F3 | js 140001006 |
0000000140001013 | 48:81EC 90000000 | sub rsp,90 |
000000014000101A | 41:B9 00000100 | mov r9d,10000 | r9d:" Á¾w"
0000000140001020 | 4C:8D05 F11F0000 | lea r8,qword ptr [140003018] |
0000000140001027 | 48:8BD1 | mov rdx,rcx |
000000014000102A | 33C9 | xor ecx,ecx |
000000014000102C | FF15 5E210000 | call qword ptr [<&MessageBoxA>] |
0000000140001032 | C9 | leave |
0000000140001033 | C3 | ret |
0000000140001034 | C8 8000 00 | enter 80,0 |
0000000140001038 | E8 2A000000 | call 140001067 | own proc: no symbols!
000000014000103D | 33C9 | xor ecx,ecx |
000000014000103F | FF15 53210000 | call qword ptr [<&SetLastError>] |
0000000140001045 | FF15 55210000 | call qword ptr [<&GetProcessHeap> |
000000014000104B | 48:8905 1E210000 | mov qword ptr [140003170],rax |
0000000140001052 | CC | int3 |
0000000140001053 | 48:8D0D C11F0000 | lea rcx,qword ptr [14000301B] | 000000014000301B:"Wow, it works!!!!"
000000014000105A | E8 A1FFFFFF | call 140001000 | own proc: no symbols!
000000014000105F | 33C9 | xor ecx,ecx |
0000000140001061 | FF15 41210000 | call qword ptr [<&RtlExitUserProc |
0000000140001067 | 48:8D0D BF1F0000 | lea rcx,qword ptr [14000302D] | 000000014000302D:"user32"
000000014000106E | 48:8D15 0B210000 | lea rdx,qword ptr [140003180] | 0000000140003180:&"MZ"
0000000140001075 | E8 21000000 | call 14000109B | own proc: no symbols!
000000014000107A | C3 | ret |
Question: is that a "feature" of X64Dbg only, do other debuggers behave the same, is there any option that I may have overlooked?
I found a workaround, see attached executables (both have an int 3), but it would be easier to just use an option... :cool:
Hi jj2007,
and where is your pdb file? In the past, the pdb was only loaded when the filenames were the same. But my pdb is loaded normally.
Hi
Maybe related, but I had issues using VS integrated debugger. The problem was and still is, that nested symbols were not resolved and an error message was displayed in the locals pane. I solved it using the linker from Visual Studio 14.0 that plays nicely with UASM. Even the latest versions of both SW are not fully compatible.
Biterider
Actually, it's an awful mess! I have four ml64 and 8 link** versions, plus UAsm, AsmC, polink (2 versions), but the only combination that creates a pdb file (without effect btw) is
Microsoft (R) Macro Assembler (x64) Version 14.10.24930.0
Microsoft (R) Incremental Linker Version 14.10.24930.0
Right now I am playing with various assembler (/Zi /Zd /Zf) and linker (/debug /cv) options, but I see nowhere the pdb and ilk files that I remember to have seen in the past :rolleyes:
Thanks, LiaoMi and Biterider. Do you actually see your own symbols?
Hi JJ
Yes, in the described combination.
Biterider
Wow, I got one working combi :thumbsup:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\msobj140.dll
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\link.exe
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\lib.exe
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\ml64.exe
BAD: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\ml64.exe
Unfortunately, no luck with UAsm64 and AsmC (\Masm32\bin\AsmC.exe /c /Zp8 /Zi /Zd /Zf /Zne /win64 \Masm32\MasmBasic\Res\Short.asm):
Microsoft (R) Incremental Linker Version 14.00.24215.1
Copyright (C) Microsoft Corporation. All rights reserved.
Creating library Short.lib and object Short.exp
Short.obj : fatal error LNK1318: Unexpected PDB error; OK (0) ''
Many changes have been made since version 14.00 :biggrin:
QuoteMicrosoft (R) Incremental Linker Version 14.00.24215.1
Copyright (C) Microsoft Corporation. All rights reserved.
Creating library Short.lib and object Short.exp
Short.obj : fatal error LNK1318: Unexpected PDB error; OK (0) ''
=> https://developercommunity.visualstudio.com/t/fatal-error-lnk1318-unexpected-pdb-error-ok-0/225957
I did a test on the following versions:
12.0.21005.1
14.0.24210.0
14.28.29337.0 <- My main version
I made tests with my sample, the results were the same everywhere except in one case, UASM and ASMC releases do not show local labels in the debugger, the main function is visible as 0000000140001000 <mainmasm_20210403_161702.
$$000000>, ml64 - 0000000140001000 <mainmasm_20210403_161611.
mainCRTStartup> and all local labels are visible - 0000000140001060 | 74 00 | JE <mainmasm_20210403_161611.
_ERROR>.
UASM mainMasm
Timestamp is 6068789f (Sat Apr 03 16:15:59 2021)
Preferred load address is 0000000140000000
Start Length Name Class
0001:00000000 000000baH .text CODE
0002:00000000 00000040H .rdata DATA
0002:00000040 00000000H .edata DATA
0002:00000040 00000074H .rdata$debug DATA
0003:00000000 0000006cH .data DATA
0003:00000070 00000008H .bss DATA
Address Publics by Value Rva+Base Lib:Object
0000:00000000 ___safe_se_handler_table 0000000000000000 <absolute>
0000:00000000 ___safe_se_handler_count 0000000000000000 <absolute>
0000:00000000 __guard_fids_count 0000000000000000 <absolute>
0000:00000000 __guard_flags 0000000000000000 <absolute>
0000:00000000 __guard_fids_table 0000000000000000 <absolute>
0001:00000000 mainCRTStartup 0000000140001000 f mainMasm.obj
0001:00000000 $$000000 0000000140001000 mainMasm.obj
0001:00000076 ProcTestingName 0000000140001076 f mainMasm.obj
0003:00000000 threadMsg 0000000140003000 mainMasm.obj
0003:00000007 rtlMsg 0000000140003007 mainMasm.obj
0003:0000001c rtlMsg2 000000014000301c mainMasm.obj
0003:00000038 errMsg 0000000140003038 mainMasm.obj
0003:0000003e Val1 000000014000303e mainMasm.obj
0003:00000040 Val2 0000000140003040 mainMasm.obj
0003:00000044 COA 0000000140003044 mainMasm.obj
0003:00000064 ValX 0000000140003064 mainMasm.obj
0003:00000070 gData 0000000140003070 mainMasm.obj
entry point at 0001:00000000
Static symbols
ASMC mainMasm
Timestamp is 606878de (Sat Apr 03 16:17:02 2021)
Preferred load address is 0000000140000000
Start Length Name Class
0001:00000000 000000baH .text CODE
0002:00000000 00000040H .rdata DATA
0002:00000040 00000000H .edata DATA
0002:00000040 00000074H .rdata$debug DATA
0003:00000000 0000006cH .data DATA
0003:00000070 00000008H .bss DATA
Address Publics by Value Rva+Base Lib:Object
0000:00000000 ___safe_se_handler_table 0000000000000000 <absolute>
0000:00000000 ___safe_se_handler_count 0000000000000000 <absolute>
0000:00000000 __guard_fids_count 0000000000000000 <absolute>
0000:00000000 __guard_flags 0000000000000000 <absolute>
0000:00000000 __guard_fids_table 0000000000000000 <absolute>
0001:00000000 mainCRTStartup 0000000140001000 f mainMasm.obj
0001:00000000 $$000000 0000000140001000 mainMasm.obj
0001:00000076 ProcTestingName 0000000140001076 f mainMasm.obj
0003:00000000 threadMsg 0000000140003000 mainMasm.obj
0003:00000007 rtlMsg 0000000140003007 mainMasm.obj
0003:0000001c rtlMsg2 000000014000301c mainMasm.obj
0003:00000038 errMsg 0000000140003038 mainMasm.obj
0003:0000003e Val1 000000014000303e mainMasm.obj
0003:00000040 Val2 0000000140003040 mainMasm.obj
0003:00000044 COA 0000000140003044 mainMasm.obj
0003:00000064 ValX 0000000140003064 mainMasm.obj
0003:00000070 gData 0000000140003070 mainMasm.obj
entry point at 0001:00000000
Static symbols
ML64 Start Length Name Class
0001:00000000 000000baH .text$mn CODE
0002:00000000 00000040H .rdata DATA
0002:00000040 00000000H .edata DATA
0002:00000040 00000074H .rdata$debug DATA
0003:00000000 0000006cH .data DATA
0003:00000070 00000008H .bss DATA
Address Publics by Value Rva+Base Lib:Object
0000:00000000 __guard_flags 0000000000000000 <absolute>
0000:00000000 __guard_fids_table 0000000000000000 <absolute>
0000:00000000 __guard_fids_count 0000000000000000 <absolute>
0000:00000000 ___safe_se_handler_count 0000000000000000 <absolute>
0000:00000000 ___safe_se_handler_table 0000000000000000 <absolute>
0001:00000000 mainCRTStartup 0000000140001000 f mainMasm.obj
0001:00000076 ProcTestingName 0000000140001076 f mainMasm.obj
entry point at 0001:00000000
Static symbols
0001:00000000 $$000000 0000000140001000 mainMasm.obj
0003:00000000 threadMsg 0000000140003000 mainMasm.obj
0003:00000007 rtlMsg 0000000140003007 mainMasm.obj
0003:0000001c rtlMsg2 000000014000301c mainMasm.obj
0003:00000038 errMsg 0000000140003038 mainMasm.obj
0003:0000003e Val1 000000014000303e mainMasm.obj
0003:00000040 Val2 0000000140003040 mainMasm.obj
0003:00000044 COA 0000000140003044 mainMasm.obj
0003:00000064 ValX 0000000140003064 mainMasm.obj
0003:00000070 gData 0000000140003070 mainMasm.obj
Probably this is a problem of the debugger itself :icon_idea: