WinRT originate error - 0x80040155

@Th69 sagte in WinRT originate error - 0x80040155:

IID_ITfTextInputProcessor

Hallo Th69,

vielen Dank das ist ja interessant, die Funktion wird von meinen Komponenten nicht direkt angerufen, danke für den Hinweis,
da werde ich nachforschen.

Gruß
K aus B

Th69

Das ist ein COM-Interface.

@Th69

Hi schon klar mit Com ,

Erhalte seltsame ausgaben wenn ich den DirBrowse öffne via SHBrowseForFolder
Der Crash erfolgt danach viel später , dort ist dann die gesamte Nachrichten schleifen Behandlung kaputt.
(Vermutung Speicher Zerstörung nach dem Laden)..

Nach dem direkten öffnen des FileBrowsers kommt dann folgende Meldung im Output vom VS! :
(Scheinbar mischt China direkt mit , konnte wohl die geheimen Daten nicht absetzen ^^)

Der RPC-Server ist nicht verfügbar.
onecore\vm\dv\storage\plan9\rdr\dll\util.cpp(99)\p9np.dll!00007FFE0493F0CC: (caller: 00007FFE049393B0) LogHr(1) tid(1b54) C0000034 Msg:[瑎牃慥整楆敬☨敤楶散‬奓䍎剈乏婉ⱅ瑡牴扩瑵獥‬椦卯慴畴ⱳ渠汵灬牴‬䥆䕌䅟呔䥒啂䕔也剏䅍ⱌ⠠䥆䕌卟䅈䕒剟䅅⁄⁼䥆䕌卟䅈䕒坟䥒䕔簠䘠䱉彅䡓剁彅䕄䕌䕔Ⱙ䘠䱉彅偏久‬䥆䕌卟乙䡃佒低单䥟彏低䅎䕌呒‬畮汬瑰Ⱳ〠)] The thread 0x1b54 has exited with code 0 (0x0).

Scheint gänzlich in die Binsen gegangen zu sein, die Komponente ist weder hier w11 noch auf w10
registered. Scheint jetzt auch keinen direkten Bezug mehr zur vorherigen Meldung (post befor) zu haben.
Übersetzt heißt das in etwa :

玎牃慥正楆 respektvoll☨敤楶 Streuung奓华剈无码ⱅ瑡牴erweitern瑵獥椦卯 Abschreckungskategorieⱳqu汵灬牴䥆䕌䅟呔䥒啂䕔 auch剏䅍ⱌ⠠䥆䕌卍䕒剟䅅⁄⁼䥆䥌卟䈈䕒grave䥒䕔簠䘠䱉彅䡓 Chop充䕄䕌䕔Ⱙ䘠䱉充Partial long䥆䕌卍一䡃佒 Low single 䥟彏low䅎䕌呒畮汬rose Ⱳ〠 )

Da ist ja was faul Abschreckungskategorie lol....

Die Message kommt nur bei w11 wenn ich versuche den DirBrowser zu zeigen was auch funktioniert:

//::CopyFile(m_FileInfo[idxExisting].fname,m_FileInfo[idxNew].fname,bFailIfExists) )
CString CDlgExFiles::SelectExePath(CString Title)
{
    BROWSEINFO bi;
	static TCHAR dirname[MAX_PATH]={0};
    ITEMIDLIST *itemid;

    bi.hwndOwner      = AfxGetMainWnd()?AfxGetMainWnd()->m_hWnd:0;//over this window
    bi.pidlRoot       = NULL;
    bi.pszDisplayName = 0; 
    bi.lpszTitle      = Title;
    bi.ulFlags        = BIF_RETURNFSANCESTORS|BIF_RETURNONLYFSDIRS|BIF_STATUSTEXT|BIF_EDITBOX|BIF_VALIDATE; 
    bi.lpfn           = 0;//BrowseCallbackProc; 
    bi.lParam         = (LPARAM)NULL; 
    bi.iImage         = NULL; 

    if( (itemid = SHBrowseForFolder(&bi)) ) 
    { //extrakt pathname from folder
      SHGetPathFromIDList(itemid,&dirname[0]);
      GlobalFree(itemid); //free folder!
     
	  if(AfxGetApp())AfxGetApp()->WriteProfileString(_T("Settings"),_T("ExPath"), &dirname[0]);
    }

    return &dirname[0];
}

Das muss ich erstmal alles checken , danke für deine Hinweise !
Gruß Karsten

Quiche Lorraine

@Achromat

Probiere doch mal das Programm auf einen anderen Rechner aus.

Hatte mal ein ähnliches Problem, wo mir die Funktion OpenFile() den Prozess abschoss. Ursache war ein fehlerhaftes Explorer Plugin von OpenOffice.

@Achromat sagte in WinRT originate error - 0x80040155:

GlobalFree(itemid); //free folder!

Ich habe es noch nicht ganz raus, aber scheinbar löst GlobalFree(itemid)
Schwerste Fehlerketten aus, in den MS Examples kommt GlobalFree(itemid)
nicht vor, es steht dort seit 25 Jahren im Code ..

@Quiche-Lorraine sagte in WinRT originate error - 0x80040155:

@Achromat

Probiere doch mal das Programm auf einen anderen Rechner aus.

Danke für deine Hilfe, es wird auf tausenden Rechnern ausgeführt

Nur habe ich hier eine bestimmte W11 Situation und komme zu sehr eigenartigen Resultaten..

Ich gehe da an uralte Codestrecken dran die seit 20 Jahren keiner mehr angefasst hat .

DocShoe

Laut Doku soll der Speicher mit CoTaskMemFree freigegeben werden. Hab auch grad nen Schreck bekommen, denn iwo benutzen wir die Funktion auch und war mir da nicht sicher, ob der Speicher da nicht auch mit GlobalFree freigegeben wird. Der Zeitstempel der Quelltextdatei sagt 2017, und der Speicher wird mit CoTaskMemFree freigegeben, also funktioniert das seit min. 6 Jahren.

@DocShoe sagte in WinRT originate error - 0x80040155:

CoTaskMemFree

Danke, ich versuche das, das SHG ist sehr empfindlich.

Quiche Lorraine

@Achromat sagte in WinRT originate error - 0x80040155:

Danke, ich versuche das, das SHG ist sehr empfindlich.

Dann würde ich dir empfehlen das Programm durch Dr. Memory und Application Verifier zu jagen.

Gerade Dr. Memory zeigte zwar viele Warnungen an, ab es zeigte mir schon eine handvoll schwerwiegende Fehler.

@Quiche-Lorraine

Das macht man in unserer Generation nicht, wir mussten früher fehlerfrei in ASM Schreiben, Tools gab es keine, und genau so setzen wir fort. Es gibt immer wieder mal interessante Fehlersituationen, aber durch die Kommunikation mit anderen kommt man
noch selber beim Schreiben auf neue Ideen oder bekommt welche wie von Dir. Das ist besser als alle Tools zusammen.

Viele Grüße aus Spandau
Karsten

DocShoe

@Achromat sagte in WinRT originate error - 0x80040155:

@Quiche-Lorraine

Das macht man in unserer Generation nicht, wir mussten früher fehlerfrei in ASM Schreiben, Tools gab es keine, und genau so setzen wir fort. Es gibt immer wieder mal interessante Fehlersituationen, aber durch die Kommunikation mit anderen kommt man
noch selber beim Schreiben auf neue Ideen oder bekommt welche wie von Dir. Das ist besser als alle Tools zusammen.

Viele Grüße aus Spandau
Karsten

Aua. Du lässt dich auch im Puff peitschen, oder?
Benutzt ihr auch noch die gleiche Toolchain? CPU i386 Real Mode? Software für 1024x768?

Auch ihr seid Menschen und macht Fehler. Heutige Tools, insbesondere statische Codeanalyzer, sind in der Lage auch für den Menschen schwierig zu findende Fehler zu finden. Ich möchte auf solche Tools nicht mehr verzichten. Und ich wette mit dir, dass ein CppCheck Durchlauf interessante Dinge in eurem Quelltext findet. Ich finde es fahrlässig, solche Tools nicht zu benutzen, man sollte zumindest hin- und wieder mal seinen Quelltext mit sowas analysieren lassen.
Das hatten wir auch bei uns in der Firma:

Entwickler A: Warum benutzt du keine smart pointer?
Entwickler B: Habe ich noch nie, brauche ich nicht.
Entwickler A: Und was ist, wenn iwo ne Exception fliegt oder ein Branch ne Funktion früher verlässt? Können da Speicherlecks entstehen?
Entwickler B: Nene, auf sowas achte ich, das kann nicht passieren.
CppCheck: Guckst du hier! Und da! Und da auch noch!

Das ist schwach sinn, wer gerne abgeholt werden möchte schreibt alles aber auch alles in Java oder sonstigen
Umgebungen. Die Kern -ware aller Software wird jedoch von Experten erstellt, deren Module werden gelinkt
und benutzt , das ist der technische Regress, niemand weiß warum der Lichtschalter funktioniert, dennoch
ist er Teil des Benutzers Wirklichkeit. Nach 50 Jahren Softwareentwicklung hast Du da ne andere Meinung.
Wenn ich bei 2 Millionen Hand Code Zeilen auf jene Tools anwende um Fehler zu finden ist es vorbei.
Übrigens smart Pointer haben wir schon bei w95 anwenden können.
Leider macht sich in der Szene breit, das immer nur einer coden könne das ist man selber. ^^

Th69

Dann braucht man dir ja nicht mehr helfen.

Quiche Lorraine

@Achromat

Drei Fehler, welche von CppCheck, Dr.Memory und Testreihen entdeckt wurden.

if (fabs(Value - Mid < Border))
  printf("Wert ist innerhalb des Bandes");

SelectObject(MemDC, ThickPen);

void SwapLine(double** M)
{
  //...
}

void Solve(double Mat[5][5])
{
  //...
  SwapLine(Mat);
  //...
}

@Achromat schrieb:

Leider macht sich in der Szene breit, das immer nur einer coden könne das ist man selber. ^^

Jetzt bleib doch bitte mal sachlich.

Einige von uns (auch ich) sind sicherlich schon ein oder das andere mal mit Fehlern auf die Nase gefallen. Vor daher wollen wir uns mit solchen Tools einfach nur absichern.

Ein Klassiker welcher ich von der Uni her kenne: Kleine BUGs, große GAUs. Und das waren definitiv Experten.

@Th69 Ja auf diesen Schluss kommt man dann . Logische Entschlüsse sind die besten, einfach nahezu genial.

@Quiche-Lorraine lol tut mir leid, viel spaß damit ^^