Wenn MSVC 2012 Profiler angehängt wird, hängt die Anwendung

Ich habe eine C++ -Anwendung (sie wird mit Qt 5.8 library erstellt und arbeitet mit PostgreSQL 9.5 database, falls es relevant ist). Die Anwendung wird von MSVC 2012 compiler erstellt, ist eine 64-bit-Anwendung und sowohl die Debug- als auch die release-Versionen laufen normal für sich und unter cdb debugger.

Wenn ich versuche, die laufende Anwendung nach Visual Studio instrument (Analyse - & gt; Profiler - & gt; Attach) zu profilieren, hängt es scheinbar, sobald es versucht, etwas Sinnvolles zu tun: einfach die Größe eines Fensters ändern oder auf die Checkboxen klicken , aber jeder Versuch, neue Werte zu berechnen und in die Datenbank zu schreiben, ist nie erfolgreich, so als ob der Steuerungsfluss von einem Aufruf nicht zurückkehrt.

Wenn ich das Profiling stoppe, markiert Studio eine "hot path" Sequenz von Aufrufen RtlWalkFrameChain - & gt; RtlpWalkFrameChain - & gt; RtlpLookupFunctionEntryForStackWalks - & gt; RtlLookupFunctionTable - & gt; RtlAcquireSRWLockShared .
RtlpWalkFrameChain hat die größte Anzahl an "exklusiven Stichproben".
Der Versuch, Daten so zu filtern, dass die ersten mehreren Sekunden des Laufs ausgeschlossen werden (bis zum offensichtlichen Einfrieren), führt dazu, dass die Meldung "Keine Anrufbaumdaten verfügbar" angezeigt wird.

Ich habe keinen Artikel oder Post mit einem ähnlichen Problem gefunden.
Das Projekt wird in Qt Creator erstellt (ich habe keine Projektdatei, die Studio verstehen würde, daher kann ich keine "normale" Leistungsanalyse durchführen).
OS ist Windows 7 , genaue Version von Visual Studio ist 11.0.61219.00 Update 5.
Jede Idee zu diesem Thema wäre willkommen.

Upd: Wenn ich versuche, die Anwendung mit dem Luke Stackwalker Profiler zu profilieren, wird sie mit der Nachricht ERROR: StackWalk64-Endless-Callstack! abgebrochen. Der einzige relevante Kommentar zu der Nachricht, die ich gefunden habe, ist diese Stackoverflow-Frage . Wenn ich die Anwendung unter cdb Debugger starte und dann versuche, sie mit Luke Stackwalker zu profilieren, ist die Fehlermeldung die gleiche, aber die nachfolgende Pause im Debugger zeigt den richtigen (oder zumindest glaubhaften) Stack für alle Threads. Denn der Working-Thread-Debugger zeigt auf eine Codezeile innerhalb der Systembibliothek und geht nicht weiter, egal was ich mache (einmal mehr, ohne Profilierungsversuche läuft die Anwendung normal, Debugger oder nicht).