Debugging runbook

When to use this

Connections fail, methods are missing, or calls hang — you need a structured debugging path.

Debugging flowchart when Graft connections or calls fail

export GG_DEBUG=1
./gg ./MyLib.dll --port 8888 --httpPort 8889

Windows PowerShell:

$env:GG_DEBUG = "1"
.\gg.exe .\MyLib.dll --port 8888 --httpPort 8889

Logs incoming/outgoing binary IIP traffic to the console. Use for protocol-level issues only (verbose).

Check	Command / action
Vision loads	Open `http://localhost:<httpPort>/vision`
Module listed	Confirm public types in Vision
Ports open	`curl -I http://localhost:8889/vision`
MCP port	`curl http://localhost:8889/mcpport`
Registry	`curl http://localhost:8889/registry`

Confirm GraftConfig.host matches GG ports and protocol — Transport guide
Check config file precedence — env may override code — GraftConfig reference
Confirm the Graft package installed from the correct registry URL — Install a Graft

Symptom	Fix
Port 80 permission denied	Use `--port 8888 --httpPort 8889`
Module not loaded	Explicit `--modules`; correct `--runtime`
Wrong runtime (CLR vs netcore)	Match DLL target framework
Java fails	Use JAR paths; check `JAVA_HOME`
Python/Ruby deps missing	Install deps in host environment
CORS errors in browser	Ports and CORS
Firewall blocks	Open WS/TCP/HTTP ports

Use Graftcode Vision Try it out to invoke methods without writing consumer code:

Graftcode Vision Try it out panel for an instance method, with constructor parameters and a Run control

If Try it out succeeds but your application fails, the issue is likely consumer configuration, registry install, or auth — not Gateway exposure.