Wednesday, December 04, 2019

visual ...

  • objdump equivalent in VS world is DUMPBIN. mingw objdump (elf) will not work on msvc objects (coff), and djgpp's coff tool won't work either (MS-DOS executables no longer running on 64-bit systems).
  • /GL is your archenemy if you planned any guru meditation on .obj files. It will kill about everything the file may have as meta-information, including symbol tables. How one can still link such files has not yet been researched. dumbpin will shout File Type: ANONYMOUS OBJECT at you if that flag was present when compiling.
  • If you ever see 'Rtl*' in some windows code, stop thinking about RealTech(Tek?) network cards. This is just Run Time Library, doing weirdo wrappers around standard functions such as memcpy for whatever reasons. Have a look in wdm.h or google the function name to find where it is defined.
  • it may be sensitive to MIDL_PASS, _MEMCPY_INLINE_ and _CRTBLD
  • There is no /Ldirectory_path in (my setup of?) link.exe, but it is sensitive to the %LIB% environment variable.
  • The amount of information /VERBOSE produces on link.exe explains why we don't see anything in the map file unless things went ok
  • Speaking of linking, DUMPBIN /imports exe_or_dll is what you'll use instead of /usr/bin/nm and DUMPBIN /depends when trying to figure out what DLL is preventing your stuff to run. Note that DLL-loading function will return the same error code whether the requested module or any of its dependencies has an issue, and that will be a 'no such file' for you, sir.
  • It looks like sysinternals is now an official MS resource for system monitoring. It's just ... Dudes, did you really had to sell its documentation ?
  • I won't ever maintain a .sln file in parallel with the SConscript that built the binary I want to debug because I know devenv /debugexe TakeOverTheWorld.exe
  • don't even try to use a Debug binary over a machine where there is no visual studio installed. It will miss its MSVCP140d.dll no matter how many attemps vcredist.x64.exe does at populating c:\windows\system32 with release dlls.
  • don't forget to disable VS Code tracking & telemetry options if you dare to use that.
  • I wish so much I had heard of c:\windows\system32\where.exe, the equivalent of /usr/bin/whereis ...
  • There's no killall, but if you have powershell running, there's taskkill /IM buggy.exe /F
  • If you want to know which #defines are still present after pre-processing your code, add /d1PP to your /P or /E switch
  • If your compiler still pretends that some symbols are undeclared while pre-processing output clearly shows they are there: that sounds like stdafx.h is messing things up. When doing a 'regular' compilation, the compiler ignores whatever #include statements you have and instead blindly use pre-compiled headers that are built only using stdafx.h !

And I still have to check the details of pdb files, dump files and remote debugging... edit: hopefully, one can invoke dumpbin from MSYS shell too. I'll just have a disasm bash function to wrap that around from now on:
disasm() {
   /c/Program\ Files\ \(x86\)/Microsoft\ Visual\ Studio\ 14.0/VC/bin/amd64/dumpbin.exe -disasm $* ; 
   }

2 comments:

PypeBros said...

And don't forget ssh -R 19999:localhost:22 sourceuser@138.47.99.99 may be useful to use SSH tunnels the other way round (just in case you don't want to deal with RDP every single time you connect)

ivanti said...

unfortunately, dumpbin /imports only gives you the name of the requested DLL. Not the actual path of the files used. If you happen to have multiple files with that name (hello, Dever ...), you may need to invoke perfmon /res, switch to the 'CPU' tab, tick the box for the process you're interested in and check the path there.