Crash bei Verbindung zu WMI / COM ***25 EURO Gutschein für Fix***
-
Man kann nur hoffen das er niemals beruflich programmiert. Sowas geht mal gar nicht.
-
echt mal jetzt
-
Kenner der Frickler schrieb:
Man kann nur hoffen das er niemals beruflich programmiert. Sowas geht mal gar nicht.
Ich weiß nicht... Ich würd dir echt gern Recht geben, und in dem Fall stimmt es wohl auch, aber ich hab schon öfter Fälle in realen Projekten gesehen, wo man gesagt hat, ok, jetzt funktionierts, aber keine Ahnung, warum.
-
jah1993 schrieb:
Der Wettbewerb ist damit beendet.
Ich konnte zwar den Grund nicht herausfinden und fixen, dafür habe ich es geschafft die Access Violation abzufangen und ein simples Looping Retry implementiert. Ich weiß, dass ich nicht schön - aber es funktioniert!
Unfassbar...
-
Was solls, er programmiert wahrscheinlich nur die Kraftstoffsteuerung für einen Airbus oder so...
da stört sich doch kein Feingeist dran.
Dass die Exception irgendwelchen andern Speicher rein zufällig auch verändern könnte, ist ja auch egal... und wen stört es schon wenn ein Programm abstürzt... Man ist doch daran gewöhnt das Microsoft Programme nur Scheiße sind dank solcher Programmierer...
-
Ihr seit also der Meinung, es ist sinnvoller weitere xxx Stunden (und es werden nicht wenige sein) in einen Fehler zu stecken, der rein 0 produktiven Wert erbringt ihn sauber zu fixxen, wenn es auch so geht ?
Als Techniker gebe ich euch recht, aber als praktiker der einfach das Projekt weiter bringen muss war die Entscheidung einfach.
Macht es doch besser, und fixt solche Fehler wenn ihr meint. Dann beschwert euch aber nicht, dass die Projekte 5x länger dauern als geplant/Budget da ist.
Ich steh zu dieser Lösung.
-
jah1993 schrieb:
Ich steh zu dieser Lösung.
Stehst du auch zu deinem Eingeständnis???
jah1993 schrieb:
Ich weiß, dass ich nicht schön
-
klar steh ich dazu. Meinst du das wurmt mich nicht das ich den Fehler nicht auf die ordentliche Art habe lösen können?
Aber zum Schluss war der besagte connect code noch vor allem eigenem threading zeugs es wurde klar das es sich um eine libary inkompitiblität oder konfigurationsgeschichte handelte. Ich kann aber auch nciht ewig an der config rummachen weil dann wiederum anderen libary's zu bruch gehen.
Also musste ich mich gegen meine innere Überzeugung für die wirtschaftliche Lösung entscheiden. Wie gesagt, ihr könnt es besser machen. Es handelt sich um Consumer Software, da stirbt niemand an einer dirty solution.
-
Ich möchte deine software nicht kaufen... wer weiss was noch alles in deinem Riesen Bug drinsteckt.
-
Deine String Konvertierung sieht echt übel aus.
// Convert output to std::string std::wstring outputW(vtProp.bstrVal, SysStringLen(vtProp.bstrVal)); std::string output(outputW.begin(), outputW.end());
Nutze mal WideCharToMultiByte() oder ähnliches...
Aber zum Schluss war der besagte connect code noch vor allem eigenem threading zeugs es wurde klar das es sich um eine libary inkompitiblität oder konfigurationsgeschichte handelte. Ich kann aber auch nciht ewig an der config rummachen weil dann wiederum anderen libary's zu bruch gehen.
Also musste ich mich gegen meine innere Überzeugung für die wirtschaftliche Lösung entscheiden. Wie gesagt, ihr könnt es besser machen. Es handelt sich um Consumer Software, da stirbt niemand an einer dirty solution.
Die Konsequenz hieraus ist fatal. Ich bin kein Freund mehr von Hacks, da diese oftmals nur unter sehr gewissen Bedinugenen funktionieren, sofern sie nicht undefiniertes Verhalten nutzen. Und da dann diese Hacks eine zeitlang gut gehen, bekommst du Vertrauen in solchen Lösungen. Doch dummerweise schlagen diese Fehler irgentwann zu (anderes Betriebssystem, Rechte, PC, Mondstand,...).
Beim Bug-Fixing ist man doch ein wenig im digitalen Blutrausch. Man jagt den Fehler solang bis man ihn erlegt hat. Und wenn sich dieser immer noch versteckt dann wirft man diverse Mitteln an (Debugger, Application Verifier, Flault-Injection) an.
Ich fürchte, da must du auch mal durch...
-
Ein weniger schlimmer Workaround wäre den problematischen Code in ein eigenes Utility auszulagern, evtl. gleich ein VB-Skript das man dann über WScript.exe rausstartet.
Bzw. wenn man es selbst macht, dann kann man in dem Prozess ruhig die Access-Violation fangen und statt grossartig Fehlermeldung anzeigen einfach ein ExitProcess(1) machen.
Ist natürlich immer noch nicht sauber, denn durch irgendwas muss der Fehler ja getriggert werden, d.h. es gibt irgendwo nen mehr oder weniger schlimmen Bug in der Applikation. Denn wenn IWbemLocator::ConnectServer grundsätzlich ein Problem machen würde, dann würden hunderte Programme nimmer funktionieren -- das würde man schnell merken.
-
Ich habs paar mal laufen lassen, bei mir crasht nichts, scheint auch zu funktionieren.