如何解决Windows下的System.IO.FileNotFoundException？及Linux命令ldd、nm的Windows等效工具查询

Great question—let’s break down exactly what you need to track down that unexpected DLL load, starting with the Windows equivalents of your go-to Linux tools, plus some extra utilities tailored to your scenario.

Equivalent to Linux's ldd (Check Dynamic Dependencies) #

ldd shows shared library dependencies for a binary; on Windows, these tools do the same for EXEs and DLLs:

• dumpbin /dependents (Visual Studio Command-Line Tool)
  This is the command-line workhorse. Open the Developer Command Prompt for Visual Studio, then target your app or a suspicious DLL:

  dumpbin /dependents YourApplication.exe
  

  or

  dumpbin /dependents SuspectLibrary.dll
  

  It’ll list all direct dependencies, so you can spot if any module explicitly references "Application Server Core.dll".

• Dependency Walker (depends.exe)
  A classic graphical tool that visualizes the full dependency tree of an EXE/DLL. It highlights missing dependencies in bright red, making it easy to trace where the problematic DLL is being called. You can drag-and-drop your app or suspect DLL into it to explore the chain of references.

• Process Explorer (Sysinternals)
  If your app runs briefly before crashing, launch Process Explorer, find your app’s process, and check the DLLs tab to see loaded modules. Use the Find > Find Handle or DLL feature to search for "Application Server Core.dll"—it’ll show you exactly which process (and parent module) is trying to load it.

Equivalent to Linux's nm (Inspect Symbol Tables) #

nm lists symbols (functions, variables) in a binary. On Windows, these tools let you check exported/imported symbols to see if a DLL references the problematic library:

• dumpbin /imports (Visual Studio Tool)
  To see all functions a DLL is importing from other libraries, run:

  dumpbin /imports SuspectLibrary.dll
  

  This will explicitly list every DLL the suspect module relies on—look for "Application Server Core.dll" in the results. For a full symbol table, use dumpbin /symbols instead.

• strings (Sysinternals)
  A quick way to search for hardcoded text strings inside a binary. Run this to check if a DLL references the missing library’s name:

  strings SuspectLibrary.dll | findstr /i "Application Server Core"
  

  It’ll pick up any plaintext references to the DLL.

Bonus Tool for Your Exact Troubleshooting #

Since you’re hunting for what’s triggering a DLL load that shouldn’t happen in your client environment, Process Monitor (ProcMon) (Sysinternals) is indispensable:

1. Launch ProcMon and set a filter: Path contains "Application Server Core.dll".
2. Run your application until it crashes.
3. ProcMon will log every attempt to access that DLL, including the process ID and the module that initiated the request—this will directly point you to the culprit.

内容的提问来源于stack exchange，提问作者Dominique