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
• There's no stuff & command to send stuff in the background but we can use start stuff to have the same effect
  
• Speaking of linking, DUMPBIN /imports exe_or_dll is what you'll use instead of /usr/bin/nm and DUMPBIN /dependents 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 $* ; 
   }