L&L bleibt hängen bei der Ausgabe, Umschalten in andere App erweckt ihn wieder zum Leben

Deutschsprachiges Forum
, ,
1

Lieber Support,

Erstmal die Situation:

Windows 11 (das Problem gab es aber schon unter Windows 10)

Xbase++ (ohne das Xbp*-GUI, bei mir synchrones WIN32 mit Standard-Messageloop.)

IllDataProvider für Datenbereitstellung.

Datenanzeige im Viewer.

Erstes Symptom: Die Benutzeroberfläche friert während der Datenausgabe ein.

Das Problem tritt häufig auf, manchmal behebt es sich nach wenigen Sekunden von selber.

Manchmal aber auch nicht.

Debuggen zeigt mir dann, dass mein Thread sich entweder in LLPrintEnd oder LLPrint befindet. Die Prozess-CPU steigt auf ca. 4% (mehr kriegt der Prozess bei mir nicht) und wenn man mit dem Process Explorer in die Details geht, sieht man, dass zwei Threads sich diese 4% ca 50:50 teilen. Einer der beiden wildgewordenen Threads startete bei “win32kfull.sys+0x406dd2” und der andere bei “cmll31.dll!LlXOBStatJobOpen+0x415bc0”.

Diese beiden Threads ziehen dauerhaft soviel CPU, dass ein zusätzlicher Debug-Thread, der normalerweise alle zwei Sekunden die Speichersituation (OutputDebugString) ausgibt, nichts mehr ausgibt.

Hier kann man das Programm stehen lassen, es geht einfach nicht weiter. Klickt man aber auf das Top-Level-Fenster einer anderen Appplikation, startet die L&L-Applikation wieder und läuft dann in der Regel bis zum Schluss durch, als wäre nichts gewesen.

Habe ich einen MessageFilter registriert, der auf einen Hotkey reagieren soll, dann funktioniert der Hotkey in der Stillstandssituation auch nicht. Das heißt, L&L dispatcht bei diesem Stillstand keine Messages. Habe ich den Hotkey gedrückt (zunächst ohne Reaktion) und klicke dann in eine andere Applikation, dann wird sofort mein MessageFilter von L&L gerufen und mein Hotkey-Reaktions-Dialog erscheint. Im Callstack sieht man dann, dass der Aufruf aus LLPrintEnd/LLPrint kommt. Das heißt, L&L dispatcht dann wieder Messages.

Leider bin ich nicht im Stande zu sehen, was der L&L Thread mit dem O/S Thread hier zu schaffen hat und deswegen brauche ich Ihre Hilfe. Ich habe schon Stunden reingesteckt, das Problem selber in den Griff zu kriegen. PostMessage, AttachThreadInput, Message-Loop vorher, Message-Loop nachher, … you name it. Aber alles vergebens.

Das Problem tritt nicht nur im Viewer auf. Im Designer in der Voransicht passiert das Gleiche.

Anbei ein Screenshot-Ausschnitt der Threadsituation bei so einem Hänger.

Vielen Dank und beste Grüße

Michael Hoffmann

Hänger
Hänger424×362 33.9 KB

2

Der Case wäre in unserem Support besser aufgehoben, wir würden für die Untersuchung ein Dump-File benötigen. Die genannten Adressen sind leider nicht ausreichend, um eine Analyse durchzuführen.

Die Erstellung eines Dumps ist hier beschrieben:

3

Ich habe keine Ahnung wie XBase++ funktioniert. Anscheinend hast du aber einen Data Provider gebaut, der intern aber auch direkt mit der LL .Net Komponente arbeitet bzw. native calls macht (LLAddTable etc. - hast du in einem anderen Beitrag geschrieben). Idealerweise “kennt” ein DataProvider LL nicht direkt sondern liefert nur die Daten über die Interfaces. Vielleicht liegt hier dein Problem.
Mein DataProvider ist für OpenEdge. OpenEdge ist single threaded. Ich muss immer den Parameter LL.UseSingleThread setzen. Vielleicht hilft das auch in deinem Fall.

4

Das erinnert mich an diesen kleinen Sendung-mit-der-Maus-Beitrag mit dem Titel “Ein Loch ist im Eimer Karl-Otto”. Wenn ich im WinDbg den Dump auslösen soll, dann muss ich den Focus da erst mal hinkriegen. Und genau das lässt den L&L ja weiterlaufen, wie ich schrieb. Aber Sie haben schon ein Programm von mir im Support wegen der verschwindenden Workakreas im Drilldown. Mit etwas Glück sollten Sie damit den Fehler reproduzieren können. Das wären zwei Fliegen mit einer Klappe.

5

Das Programm kenne ich, Sie sollten gerade (oder werden zeitnah) vom Support hören. Ich kann gerne schauen, ob wir das damit nachvollziehen können. Da Sie die Stacktraces in Ihrem Screenshot hatten war ich davon ausgegangen, dass Sie den Prozess auch breaken können? Nun denn, ich werde schauen, was die Kollegen vom Support dazu meinen :slight_smile:.

6

Hallo Thomas,

danke, dass Du mir helfen möchtest. Xbase++ hat zwei Gesichter. Wenn man das native Xbase-GUI verwendet, das in einem separaten Thread läuft, dann befindet man sich in jedem Applikationsthread ganz schön im Abseits, falls man Datenaustausch über Windows-Nachrichten machen will. Denn ein synchrones Antworten auf z.B. ein SendMessage ist (ohne thread-switching) nicht möglich.

Weil ich dieses GUI nicht verwende, sondern mein eigenes 100% WIN32 API konformes, schreibe ich das immer dazu. Ich kann synchron mit dem L&L interagieren. Das ist auch die Voraussetzung für meine ILLDataProvider COM-Objekte. Ich rufe in den List&Label rein (z.B. mit LLPrint()) und List&Label ruft dann in meinem ILLDataProvider Interface synchron die Methode :DefineRow(), mit der ich dann die ganzen Feldinhalte an L&L melde. .Net nutze ich nicht.

Das ist bestechend einfach und funktioniert auch prima, also meistens.

Gibt es da draußen noch mehr Leute, die den ILLDataprovider in der vollen Breite implementiert haben?

Danke Dir und viele Grüße

Michael

7

Nee, das war der gute alte Screenshot mit der entsprechenden Taste. Das ging auch nur, nachdem ich den ganzen Windows-11-Luxus ausgeschaltet hatte, der ja auch den Focus verschiebt.

8

Hallo Michael,

mit deiner Beispielanwendung bei uns im Support kann ich das Verhalten zumindest teilweise feststellen.

Allerdings hängt sich das Programm nicht bei mir auf, es braucht ca. 6-7 Sekunden um die Vorschau im Designer zu laden. Starte ich das Programm neu zum Vergleich und klicke direkt nach Start der Vorschau wie von dir beschrieben ein anderes Fenster an, bei mir bspw. ein Datei-Explorer Fenster, lädt die Vorschau sofort.

Ich werde das daher intern einmal weiterleiten und betrachten lassen. Vielleicht finden wir ja etwas dazu.

9

Ich wusste nicht, dass es auch ein ILLDataProvider Interface für COM gibt. Ich dachte, dass gibt es nur für die .Net Komponente. Dann kann ich wirklich nicht helfen :wink:

10

Hallo Leon,

da scheinen noch andere Dinge reinzuspielen. In meiner aktuellen Test-Applikation kommt es öfter zu den Vollhängern, vor allem wenn der Report fast fertig ist. Ich hab mir was Nettes mit Hotkey und DebugBreakProcess() gebastelt, mit dem ich den Prozess ohne Focuswechsel komplett stopppen kann. Ihr braucht dann einen kompletten Prozess-Dump, sagt ihr. Wie lautet Euer Wunschkommando im WinDbg in diesem Fall?

Danke und beste Grüße

Michael

11

Hallo Michael,

meinst du etwas in Richtung von “.dump /ma C:\temp\dump.dmp” ?

Ansonsten findest du hier noch weitere Informationen zum Erstellen von Dumps (wie wir uns das vorstellen): Erstellung von Speicherabbilddateien

12

Hallo Leon,

ich hab mir doch noch den ProcDump runtergeladen und ein paar Dumps erzeugt, als der Previewer am Ende der Reporterzeugung hängen blieb und die CPU dauerhaft oben blieb. Drei davon habe ich Euch im Supportbereich hochgeladen.

Danke für die Hilfe.

Beste Grüße

Michael

13

Danke dir für die Dateien :slight_smile:

Ich habe das einmal im Kontext mit den vorigen Beobachtungen an unsere Entwicklungsabteilung weitergeleitet.

Wir würden uns dann entsprechend über den Support Case melden, sobald wir Neuigkeiten dazu haben.