EErrorHarbor
Error Library

SignTool.exe Not Found: Find the Windows SDK Path First

If a build says SignTool.exe is not found, first prove whether the executable exists in an installed Windows SDK and which SDK version/architecture owns it. This guide stops at executable/SDK discovery. If the exact full path launches successfully but the bare signtool command is not recognized, continue with the separate command-resolution guide instead of reinstalling the SDK.

Windows SDK · SignToolWindows 10/11 · Visual StudioLast reviewed Sep 27, 2026
🎯 You’re likely in the right place if:
A build, signing script or terminal says SignTool.exe cannot be found.You use Visual Studio, MSBuild, Windows SDK, WDK or a code-signing workflow.The failure occurs before the signing operation itself starts.
Choose the path that matches what you see
PowerShell finds one or more signtool.exe pathsProve one intended full path launches. If it does, SDK/tool discovery is solved; a bare-command failure belongs to the command-resolution guide.
No signtool.exe is found under Windows KitsInstall or repair the appropriate Windows SDK component.
Interactive shell finds it but the build does notThe build/CI environment has a different PATH or SDK discovery context.
Several SDK versions are installedMatch the SDK version your project/build requests. Then choose the SignTool architecture for the environment that runs it; x64 is the usual choice on a 64-bit Windows build machine, while x86 and Arm64 copies are also provided.
Difficulty: Easy–ModerateRisk: Low first
🔎 Fix #1 — locate the installed SDK copy

Use PowerShell to search the standard Windows SDK bin directory for SignTool copies. The command below intentionally shows only the first few matches for quick discovery; if several SDKs are installed, do not treat that truncated output as an authoritative SDK selection.

Get-ChildItem "${env:ProgramFiles(x86)}\Windows Kits\10\bin" -Filter signtool.exe -Recurse -ErrorAction SilentlyContinue | Select-Object -First 5 -ExpandProperty FullName

Verify: If one or more paths are returned, choose the version/architecture appropriate to the build and run that exact full path with /?. If help opens, SignTool itself is present and runnable. Do not reinstall the SDK for a later bare-command/PATH failure.

More than one result? Do not simply use the first path. Check your project or build configuration for its Windows SDK version (for example, a WindowsTargetPlatformVersion/SDK setting). Prefer that matching version. Microsoft ships separate x86, x64, and arm64 SignTool paths; use the copy appropriate for the environment running the signing step.
Did PowerShell find SignTool.exe?
ADSENSE · reserved slot after the first useful step

Why this happens

Microsoft ships SignTool as part of the Windows SDK, typically inside a versioned `Windows Kits\10\bin\\` directory. A normal shell may not have that directory on PATH even though the tool is installed.

Diagnose before changing more

1
Does an installed SDK path contain SignTool?
If yes, launch the intended copy by full path. That distinguishes executable discovery from PATH/command resolution.
2
Are you running a normal PowerShell/cmd window?
Developer Command Prompt or Developer PowerShell may provide the expected build-tool environment.
3
Is the Windows SDK component installed?
If the search returns nothing, verify the Windows SDK/Visual Studio workload rather than copying SignTool from another machine.

Fix #2 — prove the intended SDK copy launches by full path

Before changing PATH, launch the selected SignTool copy directly. Match the SDK version requested by the project/build when one is explicitly pinned; then select a tool architecture appropriate for the process/build environment. This test proves the executable itself independently of shell command resolution.

& 'C:\Program Files (x86)\Windows Kits\10\bin\\x64\signtool.exe' /?
🟡 Before changing configuration: Replace the placeholder with the version and architecture that actually exist on your machine.

Verify: Run the exact discovered SignTool path with /?. If help opens, this article's executable-discovery problem is solved. If only bare signtool still fails, move to ‘signtool’ Is Not Recognized; do not reinstall SignTool.

Did Fix #2 work?

Fix #3 — install the Windows SDK component if SignTool is absent

If no SDK copy exists, install a Windows SDK that matches the version required by your project/build. If you use Visual Studio, open Visual Studio Installer → Modify and make sure a Windows SDK component for the required target version is installed; alternatively, use Microsoft’s official standalone Windows SDK installer. You do not need to download SignTool separately—it is installed under the SDK bin path.

# After installation, locate the SDK copy again: Get-ChildItem "${env:ProgramFiles(x86)}\Windows Kits\10\bin" -Filter signtool.exe -Recurse -ErrorAction SilentlyContinue
🟡 Keep it reversible: Do not download a standalone SignTool.exe from unofficial DLL/tool sites.

Verify: After SDK installation/repair, rerun the location check and launch the intended returned signtool.exe by full path. Bare-command resolution is a separate verification step covered by the related guide.

Did Fix #3 work?

What not to do

Do not download SignTool.exe or Windows SDK DLLs from unofficial file-sharing sites.Do not add every Windows Kits version to the global PATH.Do not debug certificates or signing credentials until the SignTool executable itself can be launched.Do not reinstall the Windows SDK merely because signtool by name is not recognized after the full executable path already works.Do not choose an SDK copy solely because it appeared first in a truncated recursive search; honor an explicitly pinned project/build SDK version.

Still seeing the error?

If the exact discovered signtool.exe path opens help successfully, the executable/SDK discovery problem is solved. A later bare-command failure is command resolution; a build-only failure is build-tool path discovery; a signing failure after SignTool launches belongs to certificate/digest/signing diagnosis. Keep those failure stages separate.

1
Works by full path, fails as signtool?
Your current shell does not resolve the SDK bin directory. Prefer the Developer shell or configure the build with the exact discovered path.
2
Works interactively, fails only in MSBuild?
Inspect the MSBuild property, target, or script that supplies the signing-tool path instead of changing certificate settings.
3
Works locally, fails only in CI/CD?
Treat the runner as a separate machine. Confirm that its image contains the Windows SDK/SignTool and that the job can resolve the intended version and architecture.
Before escalating, capture:the exact build/terminal error textthe SignTool paths returned by the Windows Kits searchWindows SDK/Visual Studio versions installedwhether the failure is interactive, MSBuild, CI-only, or all threethe shell/build architecture if x86/x64 selection mattersthe project/build's requested Windows SDK version, if explicitly pinnedwhether the exact full path launches /? successfully

Common error wording

“An error occurred while signing: SignTool.exe not found.” This wording usually points to the same missing-tool or SDK-discovery problem. Follow the Quick Check above first; do not disable signing or change certificates just to hide the error.

Official references

Microsoft: SignToolOfficial location, purpose and command syntax →Microsoft: SignTool.exe (.NET Framework tools)Developer shell guidance and signing options →Microsoft: MSIX troubleshooting — SignTool in CI/CDCurrent guidance for runners where SignTool is not installed or discoverable →

Still stuck? Ask the community

Share your operating system, software version, exact error text, and which fix you already tried. Another reader may have seen the same setup.

Keep it safe: never post passwords, API keys, access tokens, recovery codes, license keys, private URLs, or confidential logs.
Powered by GitHub DiscussionsSign in with GitHub to comment. Reading comments does not require sign-in.

Loading community discussion…