WinRT originate error - 0x80040155



  • Hallo,

    auf Arbeit habe ich einen W11 Rechner sonnst eher W10 beim Ausführen meiner Programme insbesondere beim umladen von DLL's
    kommt diese Exception

    WinRT originate error - 0x80040155 : 'Die Proxyregistrierung für die IID {AA80E7F7-2021-11D2-93E0-0060B067B86E} wurde nicht gefunden.'.

    Was soll kann man davon halten, die Ausführung wird beendet, debuggen hilft nicht es gibt die Ausnahme nahe PumpMessage.

    Kommt nur im Release vor (Na wunderbar)

    Danke für Hinweise (Programm lief seit 15 Jahren fehlerfrei muss sich also auf W11 beziehen)
    Karsten aus Berlin



  • Laut The Magic Number Database | MagnumDB handelt es sich bei AA80E7F7-2021-11D2-93E0-0060B067B86E um die Komponente IID_ITfTextInputProcessor.

    Vllt. hilft dir das beim Suchen?

    Du solltest auch mal in der Registry auf beiden Systemen nach dieser GUID suchen. Da scheint wohl diese Komponente auf dem W11 Rechner nicht registriert zu sein.



  • @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



  • 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



  • @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 .



  • 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.



  • @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



  • @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. ^^



  • Dann braucht man dir ja nicht mehr helfen.



  • @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 ^^


Anmelden zum Antworten