1
  • An executable is loaded and run in WinDbg
  • It loads modules it needs at certain addresses
  • Breakpoints set/traces retrieved in this session depend on these addresses
  • When another session is started for the same executable, (either depending the on the code execution path changing dll dependency order, or some indeterministic loader behavior?) the modules are now loaded into different addresses.

It would have been helpful if there was a way to instruct windbg/loader to load the not-yet-loaded modules at given addresses. This would make certain scripts/text-comparisons much easier.

Yes, I do realize that for example, setting breakpoints relative to symbol names should be preferred instead of using fixed addreses, but being able to "reproduce" a reference debugging environment definitely has certain advantages.

Assuming we're dealing with 3rd party DLLs (that I cannot recompile with predefined loading addresses), is there a way to do this?

I was so happy to see .reload command has an address parameter, which looked like it would do exactly what I'm asking. However, even though that command would load the modules, when the program is continued (and the actual dll load is needed), it would go ahead and still load another copy(?) for the same module, and give a warning like:

WARNING: moduleX_1be0000 overlaps moduleX

So it didn't really work like I expected, thus this question!

OzgurH
  • 443
  • 2
  • 13

1 Answers1

1

WinDbg does not load modules (DLLs). The modules are loaded by the executable.

The ld and .reload commands of WinDbg do not load modules, they load symbol information (PDB files).

The process of changing the address of a module is called rebasing. It happens if the base address is not available any more, e.g. in use by a heap already. In that case, you cannot prevent rebasing at all.

One thing that might help is disabling ASLR (address space layout randomization). You can change that setting in a DLL or EXE. It's part of the COFF header:

Stud_PE changing a COFF flag

On Windows 7, there were ways to disable ASLR completely, but it's not recommended to change that setting on a per-system basis just to help you debug a single process.

Another option would be to use rebase.exe of the Windows SDK and change the base address to a virtual address that you think is more likely to be free at the time the DLL is loaded. I never did that myself, but the rebase help says:

If you want to rebase to a fixed address (ala QFE) use the @@files.txt format where files.txt contains address/size combos in addition to the filename

so, it sounds possible to define your own address.

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
  • Checking the options, yes, I've also realized the main purpose of `.reload` had to do with symbols, but the official help page for it specifically says: `In some cases, this command also reloads or unloads the module itself`. The existence address parameter wouldn't have made much sense otherwise I think. – OzgurH Mar 27 '19 at 21:51
  • As for ASLR, I did see the post in SO RE that was titled rather similar to mine, which in turn pointed me to the one you've linked. I was just trying that system-wide setting (through EMET), and it royally messed up the system. The debugger target was not working, and it was also causing problems with other applications in my case. I did also researched into rebasing options. The pages said that MS's `rebase` (does not take base address as parameter, and) sets it based on file name/hash , so it wouldn't quite guarantee clash-free base address, do you know if that's still the case? – OzgurH Mar 27 '19 at 22:03
  • @OzgurH: it's possible that messing with ASLR in Windows >7 may cause problems. Indeed some people say there are problems in Win 8.1 already: https://digital-forensics.sans.org/blog/2014/02/17/malware-analysis-and-aslr-on-windows-8-1 I've updated the answer regarding the fixed base address. Seems rather complicated. – Thomas Weller Mar 27 '19 at 22:11
  • I was hoping for more of a virtual/on-the-fly/non-intrusive kind of resolution to be honest. However, if no other answer shows up in the next couple of days, I'll try out both rebase, and PE editing suggestions to see if they achieve what I'm after........ (Thanks for quick response/edit for my comment! - rebase may work after all (assuming ASLR doesn't always win!?)) (BTW, have you noticed my answer to your 5+ year old question (#20515857)? :) ) – OzgurH Mar 27 '19 at 22:18