Debugging Windows Runtime Brokered Components

Wer mit den Windows Runtime Brokered Components arbeitet, wird eventuell versuchen, diese zu Debuggen. Standardmäßig wird das nicht klappen, da der Debugger jegliche Breakpoints innerhalb der Brokered Components ignoriert.

Wenn wir uns noch einmal vor Augen halten, wie die Brokered Components eigentlich funktionieren, wird dieses Verhalten auch klar. Die Brokered Component läuft in einem separaten Prozess – dieser Prozess ist nicht über den Debugger gedeckt. Der zweite Prozess wird “on Demand” gestartet, also immer dann, wenn er wirklich gebraucht wird und nicht dann, wenn die App startet.  Das bedeutet für uns, erst wenn wir über “new” eine Klasse der Brokered Component instanziieren, gibt es auch einen Prozess, den wir debuggen können. Der Prozess trägt immer den Namen “dllhost.exe”.

Auf diese wird automatisch dafür gesorgt, dass der Sicherheitsmechanismus, der für Windows Apps gilt und dafür sorgt, dass diese das System nicht in Gefahr bringen können aber umgekehrt auch dafür sorgt, dass die Daten der Apps sicher sind nicht komplett unterwandert, aber an einer Stelle eben aufgebohrt. In letzter Konsequenz kann die App dann doch tun, was sie will, da sie dem externen Prozess (dllhost.exe) eben beliebige Befehle mitschicken kann.

So ist auch zu erklären, warum der Debugger nicht anschlägt: Er debuggt standardmäßig nicht dllhost.exe.

Wir müssen also manuell dllhost.exe attachen. Das ist nicht weiter schwer, allerdings ist es erst möglich, nachdem “new” aufgerufen wurde. Insofern ist es wohl am einfachsten einen Breakpoint nach dem “new” Befehl zu setzen. Im Beispiel aus dem letzten Post wäre das hier:

Dann kann man die App starten und in den Breakpoint laufen lassen – der Breakpoint befindet sich innerhalb der App, wird also anschlagen.

Zu diesem Zeitpunkt wird auch der neue Prozess gestartet. Den  findet man, indem man im Debug Menü “Attach Process” wählt und absteigend nach ID sortiert und den Prozess attached. Absteigend sortieren wir, weil man dann (ziemlich) sicher sein kann, dass der oberste “dllhost.exe” Prozess der gesuchte ist.

Wenn man dann einen Breakpoint in der Brokered Component (oder in einer darin referenzierten Lib) setzt, wird er auch getroffen.

Ein kleiner Hinweis noch: Gegebenenfalls müsst Ihr bei häufigem Debuggen, Neukompilieren und Neustarten der App irgendwann mal diesen Prozess abschießen. Es kann sein, dass sonst der Build fehlschlägt. Hier helfen Tools wie Process Explorer weiter.

Comments

• Anonymous
  January 24, 2016
  The comment has been removed