Debugging

Debugging & diagnostics

The inner loop

Build the packaging project, deploy it (Visual Studio's Build → Deploy, or Add-AppxPackage -Register …\AppxManifest.xml with Developer Mode on), then open WidBar and drag your widget onto the taskbar. WidBar watches the AppExtension catalog, so once it's deployed the first time, later redeploys are picked up without restarting WidBar.

The one habit to build: close the running widget process before you redeploy. While your …ExtensionApp process is alive it locks the package files, and the deploy fails with a file-in-use error. End the process first and the redeploy is clean.

Seeing your logs

Anything you write with Debug.WriteLine or Trace.WriteLine, plus any exception that escapes one of your SDK callbacks, is forwarded to WidBar's developer console. To see it: turn on Developer mode in WidBar's settings, then open the Console page. Your output shows up tagged with your plugin id, like [Plugin:com.contoso.weather]. The console deliberately shows only widget output — WidBar's own internals stay out of your way (they go to the host log file).

System.Diagnostics.Trace.WriteLine("[Weather] forecast refreshed");

If something's going wrong before your code even runs — a bad handshake, a startup crash — check the SDK's own log at %LOCALAPPDATA%\Packages\<your-package-family>\LocalCache\Local\Temp\widbar-sdk.*.log. WidBar's host log lives at %LOCALAPPDATA%\…\Logs\widbar.log.

Attaching a debugger

Your widget runs in a process WidBar launches, not one Visual Studio started, so hitting F5 on the packaging project won't land your breakpoints once WidBar owns the process. Use Debug → Attach to Process and pick your …ExtensionApp.exe. While you're developing, a System.Diagnostics.Debugger.Launch() near the top of InitializeAsync is a quick way to catch it early.

Running the .exe on its own

If your ExtensionApp gets launched without WidBar — say you double-click the exe — it doesn't try to render a phantom taskbar preview. Instead the SDK pops a small window explaining that this is a WidBar widget and needs WidBar to run. That's expected behaviour, not a bug.

When it crashes

WidBar restarts a crashed widget with backoff. If it crashes three times in a row it gets disabled, and stays disabled until the user re-enables it (there's a Widget crash protection reset in WidBar's settings, and a Re-enable action on the widget). The practical takeaway: don't let exceptions escape InitializeAsync or the Create* methods — catch and degrade gracefully instead.

The usual suspects

If your widget never appears in the catalog, it's almost always that the package was built but not registered (deploy it), or that Name="com.widbar.widget" got changed in the manifest, or that plugin.json isn't being linked into the Public folder.

If the preview renders blank, you've almost certainly returned swap-chain or media content from CreatePreviewContent() — that can't be rasterised. Move it to the flyout.

And if the settings gear never shows up, you haven't implemented IConfigurableWidgetPlugin.

There's more in the FAQ.