Relocation Warnings and Forwarded Export Resolution on Windows 7

[i486]

Here’s a clearer, more concise rewrite that tightens the wording and structure.

---

Describe the bug

This issue covers two related bugs that, if fixed, would significantly improve analysis on Windows 7.

Bug 1: Relocation warnings shown when disabled

DLLs that do not contain relocations are currently marked with a red icon in the Modules tree, and the log displays:

Module "DLLNAME.dll" has no relocations.

This happens even when “Process relocations while parsing images” is unchecked. In this case, DLLs without relocations should not be flagged.

Bug 2: Incorrect import status for unresolved forwarded exports when scanning with forwarder checking enabled

When scanning an application that imports a DLL whose exports are forwarded to another DLL, WinDepends incorrectly marks the imports as valid (green in the PI column) even when the forwarded functions do not exist in the destination DLL.

Background / Example

On Windows 7, api-ms-win-core-synch-l1-2-0.dll may be installed in System32 by certain updates. From the Windows 7 loader’s perspective, it behaves like a normal forwarding DLL (similar to liba.dll in issue #32), forwarding exports to kernel32.dll, since the apiset schema does not recognize it.

This DLL exports 11 functions, but 6 of them (such as WaitOnAddress, WakeByAddressAll, etc.) are not available on Windows 7.

If an application that imports unavailable functions from this DLL is scanned on Windows 7:

• With forwarder checking disabled, the imports appear green, which is expected behavior.

• With forwarder checking enabled, the imports still appear green, even though the forwarded functions are missing in the target DLL.

To Reproduce

1. Download the latest FFmpeg static build.
2. Scan it on Windows 7 with forwarder checking enabled.
3. Observe that all CRT APISET forwarder DLLs (api-ms-win-crt-*.dll) show red icons and “no relocation” warnings (Bug 1).
4. Observe that WaitOnAddress, WakeByAddressAll, and WakeByAddressSingle are marked green in the PI column despite being unavailable (Bug 2).

A similar issue could likely be reproduced on Windows 10 by compiling a test application that imports Windows 11–only APIs via an apiset library.

Expected behavior

Only api-ms-win-core-synch-l1-2-0.dll should be marked with a red icon, as it is the only problematic DLL in this scenario.

When selecting the forwarder DLL (api-ms-win-core-synch-l1-2-0.dll), the APIs should be marked red if the forwarded functions cannot be found in the target DLL (kernel32.dll).

Environment

• OS: Windows 7

Additional context

I previously hesitated to report this problem because it seemed Windows 7–specific. However, as a side effect of issue #32 (kudos to @MarekKnapek for reporting and @hfiref0x for implementing the feature), WinDepends can now properly analyze applications that fail to load on Windows 7 due to newer apiset DLLs. Fixing the issues described above would make it even easier to analyze such issues. Thanks!

[MarekKnapek]

Yes, I can confirm. With the latest and greatest version of 2511-beta the example in #32 no longer works. The tool reports that the .exe depends on liba.dll and that liba.dll has no relocations, and that liba.dll is highlighted in a red color. According to your tool liba.dll no longer depends on libb.dll.

[i486]

After reading it again, I feel like ChatGPT made my post worse.

Here’s a simpler version based on the #32 example.

Compile the DLLs with relocations so the relocation-checking bug doesn’t highlight every DLL without relocations in red.

liba.dll

.386
.model flat, stdcall

option prologue:none
option epilogue:none

.data
dummy dd 1

.code

entry proc instance:dword, reason:dword, reserved:dword
	mov eax, dummy
	ret
entry endp

end

libb.dll

.386
.model flat, stdcall

option prologue:none
option epilogue:none

.data
dummy dd 1

.code

entry proc instance:dword, reason:dword, reserved:dword
	mov eax, dummy
 ret
entry endp

funcb proc a:dword, b:dword
	mov eax, [esp + 4]
	mov ecx, [esp + 8]
	add eax, ecx
	retn 8
funcb endp

end

Now check with forwarding enabled.

This is good. No red marks - everything is green when clicking liba.dll and libb.dll. This is the current and expected behavior.

Now delete libb.dll from the directory, or alternatively change the export name to funcF, and scan again with forwarding enabled.

[hfiref0x]

The first "bug" should be fixed now. Actually it was intentionally made for debugging purposes.
Second one need more research for workaround and I would probably only look on it in the next year. Thank you for reporting these issues.

[i486]

Tested the relocation fix and its working great. Thanks!

In the meantime, I’ll try to collect other icon and warning related issues here, even if they’re not necessarily related to forwarded exporting or Windows 7.

1. Modules Tree Depth : 6
2. Application directory is moved to the top

Wireshark.exe from WiresharkPortable64_4.6.2.paf.exe

Wireshark.exe imports from Qt6Gui.dll
Qt6Gui.dll imports CreateDXGIFactory2 from C:\Windows\System32\dxgi.dll
CreateDXGIFactory2 not available on C:\Windows\System32\dxgi.dll

The bugs:

1. No "dxgi.dll contains export errors" warning in the console window.
2. No red icon on either QT6GUI.DLL or DXGI.DLL
3. Can't expand DXGI.DLL aka "+" doesn't show next to DXGI.DLL

Will try to reproduce on Windows 10 later.

No rush at all. Please take your time, and I wish you a wonderful holiday season.

EDIT:

Yeah, I can reproduce them on Windows 10

[hfiref0x]

I reviewed original Dependency Walker behavior on this:

When there is no forward module LIBB found Dependency Walker marks LIBB module as not found - WinDepends replicate this
When there is forward in exports used by LIBA Dependency Walker marks it as green with dot - WinDepends replicate this
Dependency Walker adds synthetic module into the module view if it encounters forwarder - WinDepends replicate this

I can review this on WinDepends side so it will mark as red all modules with missing dependencies but this brokes original Dependency Walker display style layout.

Or I can set red mark on parent module only for missing forwarders (and this will be enabled only when Expand forwarders is enabled).

Regarding to this:

The bugs:

No "dxgi.dll contains export errors" warning in the console window.
No red icon on either QT6GUI.DLL or DXGI.DLL
Can't expand DXGI.DLL aka "+" doesn't show next to DXGI.DLL

That's intentional. If WinDepends meets duplicate module in tree it stops it propogation because it's already somewhere in the tree (use Highlight Original Instance) and propagating this node is pointless and resource-consuming - otherwise we will have tons of duplicate nodes and few gigabytes of RAM wasted.

[i486]

Honestly, I've only used Dependency Walker a handful of times, so I'm not really familiar with its historical behavior.

That said, if I had been a programmer back in the Vista era, when Dependency Walker was actively developed, I probably would have considered this a bug and reported it. The main program will literally crash if its direct dependency (LibA) doesn't resolve everything correctly to its forwarded dependency LIBB.dll . Now i’m just guessing here, but could it be that these issues were never marked in red simply because forwarded exports weren’t very common at the time, and not many people ran into or reported the problem?

I can review this on WinDepends side so it will mark as red all modules with missing dependencies but this breaks original Dependency Walker display style layout.

I really hope you choose that approach and improve on what Dependency Walker originally missed. Personally, this would save me a lot of time, and I think future users would find it very useful too.

To give a one real example, I recently analyzed an application where LIBA showed 12 green funcX functions. But when I clicked LIBB, there were like 60 total funcX functions (25 red and 35 green). If I had wanted to know which forwards from LIBA weren't actually available in LIBB, I would have had to click between LIBA and LIBB dozens of times while mentally remembering the function names.

Now imagine a more complex case where program.exe imports APIs from a dozen different DLLs, many of which have dozens of forwarded exports, and the target DLLs may or may not have those functions. You'd essentially need to expand the entire tree and click through everything to identify the actual missing functions required by the main application.

With all these being said, I do understand the opposing viewpoint. From the perspective of program.exe, everything it imports from LIBA.dll technically exists, so one could argue those entries shouldn’t be marked red. I would agree with that interpretation only if forwarder checking were completely disabled and the tree depth setting were set to 0.

1. No "dxgi.dll contains export errors" warning in the console window.
2. No red icon on either QT6GUI.DLL or DXGI.DLL
3. Can’t expand DXGI.DLL (no “+” icon)

Yeah, I suspected something like that for 3. But does this mean 1 and 2 also can't be fixed, or could those still be addressed?

Anyway, I really appreciate the work and continuous improvements you’ve been making to this tool. I haven’t tried the command-line interface yet, but I’m actually pretty excited about it and will check it out later. Thanks again for all the effort you’re putting into this.

[hfiref0x]

@i486
Check the devRC1 branch. Its experimental for issues you described:

1. Propagate forwarder errors to parent
2. Warning for forward errors
3. Validate forwards against target
4. Duplicate module error propagation
5. Mark unresolved forwarded exports

[i486]

@hfiref0x

Hi

I am currently running a kind of split brain Windows 7 system where i manually cloned only the Windows & ProgramData folders to a different drive and dirty changed the system originally used to run Windows from C: to I: as a temporary workaround for NVMe drive dying/freezing the system randomly. I know there are hardlinks and SxS, etc stuff in Windows folder. While i believe i handled most of these stuff, there is a high chance something is broken and could affect Windepends results. Basically, don't take these reports as serious for now. In a few days, I'll get some new ssd and will retest properly after installing Win7/Win10 vms.

[i486]

I’ll comment on anything that looks odd as I test for now, and then edit the notes later in a few days.

For some reason, these two keep showing up as red, unresolved C functions in the export window. The icon should indicate a normal forwarded export.

No difference when increasing module tree depth

Previous version for reference

[i486]

Same Wireshark.exe as #39 (comment)

Current setting: Depth: 1 and forwarder checking enabled.

Everything except CRT forwarders shows red icons. I’ll attempt to test it more thoroughly in a few days to hopefully figure out why.

Edit1: Still same after disabling forwarding checks.

But now we can see a red icon for DXGI.dll, and there is also a warning saying:
“Module I:\Windows\system32\dxgi.dll contains export errors.”

So it looks like the two issues mentioned below have been fixed. Nice!

No "dxgi.dll contains export errors" warning in the console window.
No red icon on either QT6GUI.DLL or DXGI.DLL

That said, I’m not sure whether QT6GUI.DLL showing a red icon is actually caused by dxgi.dll or by something else, since everything is currently showing as red.

BTW: Depth: 0 screenshot just for reference