‘signtool’ Is Not Recognized: Fix PATH and SDK Resolution
If a shell, build, IDE task or CI job says 'signtool' is not recognized as an internal or external command, that failing process cannot resolve the command. First prove whether signtool.exe exists, then prove which SDK version/architecture the workflow intends to use and what environment the failing process actually receives. A terminal where SignTool works does not prove MSBuild, an IDE, service, scheduled task or CI step sees the same PATH.
signtool, or a build/CI job says the command is missing.You need to distinguish a PATH/environment problem from SignTool actually being absent.In PowerShell, check command resolution first, then search the Windows SDK if the command is unresolved.
Get-Command signtool.exe -ErrorAction SilentlyContinueGet-ChildItem "${env:ProgramFiles(x86)}\Windows Kits\10\bin" -Filter signtool.exe -Recurse -ErrorAction SilentlyContinue | Select-Object -First 10 -ExpandProperty FullNameInterpret the result: if the first command returns nothing but the second returns an SDK path, the executable exists but your current environment cannot resolve signtool. If neither finds it, switch to SignTool.exe Not Found instead of editing PATH.
Why Windows says ‘signtool’ is not recognized
SignTool is installed with the Windows SDK under a versioned SDK bin directory. A normal cmd or PowerShell session does not necessarily include that versioned directory on PATH. Visual Studio Developer Command Prompt and Developer PowerShell are designed to load build-tool environment settings, which is why the same command can work there but fail in a normal terminal.
Diagnose the environment before changing PATH
Take a path returned by the SDK search and run it with
/?. If help opens, the binary is healthy enough to stop troubleshooting installation.If yes, the difference is the environment, not the certificate you intend to use later.
Capture the environment inside that exact process/job. Parent-process startup time, service accounts and pipeline step boundaries can all make its PATH differ from your interactive shell.
Fix #1 — use the exact SDK path
This is the safest proof and often the cleanest build configuration because it avoids a machine-wide PATH edit. Replace the placeholders with a path that actually exists on your machine.
& 'C:\Program Files (x86)\Windows Kits\10\bin\<SDK_VERSION>\x64\signtool.exe' /?Verify: SignTool help should appear from the exact SDK copy you selected. Record that full path/version/architecture. This proves that copy can launch; it does not yet prove the original failing build process resolves the same executable.
Fix #2 — use Visual Studio Developer PowerShell or Command Prompt
If Visual Studio is installed, open its Developer PowerShell or Developer Command Prompt and test the command there. Microsoft documents these shells as the normal way to run SignTool in a Visual Studio environment.
signtool /?Verify: if signtool /? works only in the Developer shell, keep using that environment for the signing/build step or configure the build with the exact SDK path.
Fix #3 — test a session-only PATH before making it persistent
If a script truly needs the plain signtool command, test the correct SDK directory in the current PowerShell session first. This disappears when the shell closes and is safer than immediately changing the machine PATH.
$env:Path = "C:\Program Files (x86)\Windows Kits\10\bin\<SDK_VERSION>\x64;" + $env:Path
signtool /?Verify: in the same session run Get-Command signtool.exe and confirm it resolves to the intended SDK copy. Then rerun the original failing command from its real process/context; a successful interactive-shell test alone is not final verification.
Works locally but not in CI/CD?
Treat the runner—and each relevant job/container/step—as its own environment. First search for the executable inside the failing job. If absent, provision the supported Windows SDK/tooling there; if present, select the intended SDK copy and expose its directory to the step/process that invokes signing. Do not infer runner state from your development PC or from a different pipeline step.
Verify: make the pipeline print the resolved SignTool path and run signtool /? before the signing command. That separates tool discovery from later certificate/signing failures.
What not to do
Still seeing the error?
Get-Command signtool.exethe full SDK paths returned by the Windows Kits searchwhether the exact path plus /? worksthe SDK version/architecture your build expectsthe PATH visible inside the failing process or runnerthe exact SignTool full path, SDK version and architecture selected for the workflowwhether the failure follows cmd/PowerShell only or the actual MSBuild/IDE/service/task/CI processthe resolved SignTool path printed inside the exact failing job/stepthe first different error after command resolution succeedsIf the SDK search returns no executable at all, the correct next page is SignTool.exe Not Found: Find the Windows SDK Path First. If the executable launches and your next error mentions certificates, digest algorithms, timestamps or file signing, you have moved past command discovery and should troubleshoot that new error separately.
Official references
Still stuck? Ask the community
Share the exact shell/build error, the SDK paths you found, and whether the full executable path works. That makes the next diagnosis much faster.
Loading community discussion…
Comments could not load here. Open ErrorHarbor Discussions on GitHub →