c++ Programme starten plötzlich nicht mehr auf fremde Rechner
- Ersteller Devastators
- Erstellt am
Devastators
Grand Admiral Special
Ich hab hier ein C++ Programm, ehemals unter VS6 geschrieben aber mittlerweile in VS2005 portiert.
Das Programm nutze ich so schon seit gut 5 oder 6 Monaten und hatte auch noch nie diese Probleme.
Kollege hat einen Fehler gefunden, den ich schnell beseitigen konnte (division durch Null, also nix besonderes)
Als ich ihm die neue Version geben wollte, schmiert bei ihm bei Programmstart sofort das gesamte Programm ab
Bis zum Fehlerloggen kommt das Programm nicht, es muss wohl bei der Startphase vor den ersten Programmcodes das Zeitliche segnen.
Ich habe das jetzt an mehreren Rechnern ausprobiert, nirgendwo will mein Programm noch starten, bei mir macht es jedoch keine Probleme.
Ältere Backups laufen einwandfrei, doch wenn ich die neu kompiliere (also mit Stand letzter Woche) tritt auch dort der Fehler auf.
Irgendwas scheint sich am VisualStudio verstellt zu haben
Wenn ich mein Projekt auf einem fremden schiebe und dort kompilieren lasse, funktioniert das Programm auch wie gewohnt, nur meine kompilierung macht Müll.
Als Debug-Version kompiliert kommt wenigstens noch eine etwas ausführlichere Fehlermeldung:
... weil die Anwendungskonfiguration nicht korrekt ist...
Ich bin jetzt über jeden Tipp dankbar, mein VS2005 wieder ans laufen zu bekommen.
Bei VS6 war ich ja schon gewohnt, dass hier und da mal die Arbeitspfade gelöscht wurden...
Das Programm nutze ich so schon seit gut 5 oder 6 Monaten und hatte auch noch nie diese Probleme.
Kollege hat einen Fehler gefunden, den ich schnell beseitigen konnte (division durch Null, also nix besonderes)
Als ich ihm die neue Version geben wollte, schmiert bei ihm bei Programmstart sofort das gesamte Programm ab
Bis zum Fehlerloggen kommt das Programm nicht, es muss wohl bei der Startphase vor den ersten Programmcodes das Zeitliche segnen.
Ich habe das jetzt an mehreren Rechnern ausprobiert, nirgendwo will mein Programm noch starten, bei mir macht es jedoch keine Probleme.
Ältere Backups laufen einwandfrei, doch wenn ich die neu kompiliere (also mit Stand letzter Woche) tritt auch dort der Fehler auf.
Irgendwas scheint sich am VisualStudio verstellt zu haben
Wenn ich mein Projekt auf einem fremden schiebe und dort kompilieren lasse, funktioniert das Programm auch wie gewohnt, nur meine kompilierung macht Müll.
Als Debug-Version kompiliert kommt wenigstens noch eine etwas ausführlichere Fehlermeldung:
... weil die Anwendungskonfiguration nicht korrekt ist...
Ich bin jetzt über jeden Tipp dankbar, mein VS2005 wieder ans laufen zu bekommen.
Bei VS6 war ich ja schon gewohnt, dass hier und da mal die Arbeitspfade gelöscht wurden...
Crashtest
Redaktion
☆☆☆☆☆☆
starte mal Dependency Walker auf einem "fremden" PC
gibts unter http://www.dependencywalker.com/
öffne darin dein Programm und lasse es mit F7 starten
ggf. steht schon vor dem "start" eine oder mehre Fehlermeldungen inkl. Pfaden zu Dateien und fehlende Dateien.
Es liegt so gut wie sicher an den Visual C 2005 Redist Dateien.
Seit einem Windowsupdate wurden neue Versionen installiert, auf die nunmehr beim neukompilieren verlinkt wird, fehlen diese Dateien oder sind in einer niedrigeren Version vorhanden, kommt oft diese Fehlermeldung.
ggf mal dies hier durch lesen
http://social.msdn.microsoft.com/Forums/en/vcgeneral/thread/793f1dc8-bdd5-429f-8d42-589116cb0061
gibts unter http://www.dependencywalker.com/
öffne darin dein Programm und lasse es mit F7 starten
ggf. steht schon vor dem "start" eine oder mehre Fehlermeldungen inkl. Pfaden zu Dateien und fehlende Dateien.
Es liegt so gut wie sicher an den Visual C 2005 Redist Dateien.
Seit einem Windowsupdate wurden neue Versionen installiert, auf die nunmehr beim neukompilieren verlinkt wird, fehlen diese Dateien oder sind in einer niedrigeren Version vorhanden, kommt oft diese Fehlermeldung.
ggf mal dies hier durch lesen
http://social.msdn.microsoft.com/Forums/en/vcgeneral/thread/793f1dc8-bdd5-429f-8d42-589116cb0061
Zuletzt bearbeitet:
Devastators
Grand Admiral Special
Ein Windows Update, hmmm
ich fress ein Besen wenn es das ist
Ich glaub gestern oder vorgestern hab ich die neusten Updates installiert
Edit:
Also er meldet auf jeden Fall die fehlende msvcr80.dll auf dem fremden Rechner.
Packe ich diese jedoch in das Arbeitsverzeichnis, meldet er zwar den Fehler nicht mehr doch starten will das Programm dennoch nicht.
ich fress ein Besen wenn es das ist
Ich glaub gestern oder vorgestern hab ich die neusten Updates installiert
Edit:
Also er meldet auf jeden Fall die fehlende msvcr80.dll auf dem fremden Rechner.
Packe ich diese jedoch in das Arbeitsverzeichnis, meldet er zwar den Fehler nicht mehr doch starten will das Programm dennoch nicht.
Zuletzt bearbeitet:
Nachtschicht
Admiral Special
Redistributable Package ist auf den Anwendungsrechnern installiert?
http://www.microsoft.com/downloads/...ee-a3f9-4c13-9c99-220b62a191ee&displaylang=en
http://www.microsoft.com/downloads/...ee-a3f9-4c13-9c99-220b62a191ee&displaylang=en
Crashtest
Redaktion
☆☆☆☆☆☆
es reicht nicht, dass die msvc*.dll im selben Ordner liegen, die müssen auch im WinSXS registriert sein, daher einfach die VC Redist mit liefern, installieren, danach sollte es funktionieren
Quelle
http://www.microsoft.com/downloads/...FamilyID=766a6af7-ec73-40ff-b072-9112bab119c2
ich hatte dieses Problem vor kurzem auch mit TwoDees neuen BOINC
Quelle
http://www.microsoft.com/downloads/...FamilyID=766a6af7-ec73-40ff-b072-9112bab119c2
ich hatte dieses Problem vor kurzem auch mit TwoDees neuen BOINC
Crashtest
Redaktion
☆☆☆☆☆☆
Ich als Delphianer keine solche Probleme auch, naja ab und zu:
entweder man liefert die Laufzeitdlls mit oder muss halt die Anwendung so kompilieren, dass die Laufszeitdlls nicht mehr benötigt werden -> dabei wird die Anwedung jedoch einige MBs größer....
Dieses WinSXS/MSVC* Problem kann man umgehen, wenn man die Anwendung mit VC6 kompiliert
Naja ob man unbedingt ein wichtiges Systemupdate restlos entfernen kann, bei Microsoft ?
entweder man liefert die Laufzeitdlls mit oder muss halt die Anwendung so kompilieren, dass die Laufszeitdlls nicht mehr benötigt werden -> dabei wird die Anwedung jedoch einige MBs größer....
Dieses WinSXS/MSVC* Problem kann man umgehen, wenn man die Anwendung mit VC6 kompiliert
Naja ob man unbedingt ein wichtiges Systemupdate restlos entfernen kann, bei Microsoft ?
Ray
Grand Admiral Special
Mach doch mal einen Build mit statischen Runtime Libraries.
Je nachdem, was Du da entwickelt hast, wird die Exe möglicherweise gar nicht mal soo viel größer werden. Ein paar hundert KB größere Exe, dafür problemloser Betrieb auf diversen Rechnern, ist mir jedenfalls lieber als dieses ständige Drama mit den nicht passenden DLLs.
Devastators
Grand Admiral Special
Ich werde mich damit Montag weiter beschäftigen, jetzt hab ich erstmal WE 
Es ist aber schon erstaunlich was das passiert ist, denn diese Probleme hatte ich die letzten 5 Jahre nicht 1 einziges Mal
Einzig die msvcrt.dll macht immer Schwierigkeiten und liefern wir im Arbeitsverzeichnis mit.
k.A. was sich Microsoft da gedacht hat
So richtg kompliziert wird es ja erst, wenn irgendwelche FIrmen in Indien oder China solche Problem ebekommen und ich hier das Problem nicht nachvollziehen kann.
Es ist aber schon erstaunlich was das passiert ist, denn diese Probleme hatte ich die letzten 5 Jahre nicht 1 einziges Mal
Einzig die msvcrt.dll macht immer Schwierigkeiten und liefern wir im Arbeitsverzeichnis mit.
k.A. was sich Microsoft da gedacht hat
Das wäre sicherlich die letzte funktionierende Möglickeit, nur behebt das nicht das eigentliche Problem.
So richtg kompliziert wird es ja erst, wenn irgendwelche FIrmen in Indien oder China solche Problem ebekommen und ich hier das Problem nicht nachvollziehen kann.
Devastators
Grand Admiral Special
So, es ist Montag Morgen, das ganze WE hab ich mich schon drauf gefreut 
ALSO:
VC Redist: hat nichts gebracht
Build mit statischen Runtime Libraries
Da tu ich mich noch ein wenig schwer, da ich damit noch nie rumgespielt habe.
Ich habe in den Projekteinstellungen die "Verwendung von MFC" auf statisch gestellt, konnte dann aber nicht weiter linken.
Gut 20 (Microsoft-) Funktionen meldet der Linker als bereits in der msvcr80.dll gefunden.
Als "öffentliche DLL" meckert er ein Teil meiner eigenen Funktionen an, sowie zuletzt die gwmain
Da komme ich also momentan auch nicht weiter 
Ich werde jetzt erstmal einen Testrechner komplett aktualisieren und schauen, ob das Problem auch wirklich durch ein Windows Update zu beheben ist.
.
EDIT :
.
Windows\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_e6967989
Das ist der Ort des Bösen!
Die VC80 mit Versionsnummer: 4053 am Ende...
Diesen Ordner und folglich auch diese DLL meckert er auf den Testrechnern an (fehlen halt).
Ich klapper schon alle Updates ab und hoffe, dass irgendwo die DLL aktualisiert wurde...
WindowsXP-KB942288-v3-x86.exe
dort sollte auch die richtige Version geliefert werden, aber nach der Installation fehlte sie dennoch
So, ich habe jetzt alle updates installiert und trotzdem wird die neue dll nicht kopiert.
Ich habe jetzt keine Ahnung woher ich die neuere Version habe...
Wie kann ich denn VS2005 davon überzeugen, einfach eine ältere Version der DLL beim dynamischen Linken zu benutzen?
Das würde mir doch vollkommen ausreichen ?!?
.
EDIT :
.
das ist von 2006
Dort wird bestimmt nicht die 1 Monat alte DLL vorhanden sein
WindowsXP-KB942288-v3-x86.exe
das ist wohl nur der Windows-Installer
Auf einem zweitrechner habe ich jetzt alle .Net (VS2005) Updates installiert und scheinbar läuft es dort wieder.
Jetzt muss ich nur noch ein Installer finden, der kein VisualStudio verlangt
--
So, nachdem ich fast den gesamten Tag damit rumprobiert habe irgendwie die DLLs auf den "Clientenrechner" zu bekommen bin ich nun tatsächlich den Schritt gegangen und habe das Update bei mir deinstalliert.
Bei dem Update handelt es sich übrigens um das KB971090 Sicherheitsupdate für VS2005.
Dieses Update installiert die neuen DLLs.
Ich habe leider nicht herausgefunden, wie ich das Zeugs auf dem Clientenrechner installiert bekomme, da es (noch?) kein entspr. Update für die Clients gibt.
ALSO:
VC Redist: hat nichts gebracht
Build mit statischen Runtime Libraries
Da tu ich mich noch ein wenig schwer, da ich damit noch nie rumgespielt habe.
Ich habe in den Projekteinstellungen die "Verwendung von MFC" auf statisch gestellt, konnte dann aber nicht weiter linken.
Gut 20 (Microsoft-) Funktionen meldet der Linker als bereits in der msvcr80.dll gefunden.
Als "öffentliche DLL" meckert er ein Teil meiner eigenen Funktionen an, sowie zuletzt die gwmain
Da komme ich also momentan auch nicht weiter Ich werde jetzt erstmal einen Testrechner komplett aktualisieren und schauen, ob das Problem auch wirklich durch ein Windows Update zu beheben ist.
.
EDIT :
.
Windows\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_e6967989
Das ist der Ort des Bösen!
Die VC80 mit Versionsnummer: 4053 am Ende...
Diesen Ordner und folglich auch diese DLL meckert er auf den Testrechnern an (fehlen halt).
Ich klapper schon alle Updates ab und hoffe, dass irgendwo die DLL aktualisiert wurde...
WindowsXP-KB942288-v3-x86.exe
dort sollte auch die richtige Version geliefert werden, aber nach der Installation fehlte sie dennoch
So, ich habe jetzt alle updates installiert und trotzdem wird die neue dll nicht kopiert.
Ich habe jetzt keine Ahnung woher ich die neuere Version habe...
Wie kann ich denn VS2005 davon überzeugen, einfach eine ältere Version der DLL beim dynamischen Linken zu benutzen?
Das würde mir doch vollkommen ausreichen ?!?
.
EDIT :
.
das ist von 2006
Dort wird bestimmt nicht die 1 Monat alte DLL vorhanden sein
WindowsXP-KB942288-v3-x86.exe
das ist wohl nur der Windows-Installer
Auf einem zweitrechner habe ich jetzt alle .Net (VS2005) Updates installiert und scheinbar läuft es dort wieder.
Jetzt muss ich nur noch ein Installer finden, der kein VisualStudio verlangt
--
So, nachdem ich fast den gesamten Tag damit rumprobiert habe irgendwie die DLLs auf den "Clientenrechner" zu bekommen bin ich nun tatsächlich den Schritt gegangen und habe das Update bei mir deinstalliert.
Bei dem Update handelt es sich übrigens um das KB971090 Sicherheitsupdate für VS2005.
Dieses Update installiert die neuen DLLs.
Ich habe leider nicht herausgefunden, wie ich das Zeugs auf dem Clientenrechner installiert bekomme, da es (noch?) kein entspr. Update für die Clients gibt.
Zuletzt bearbeitet:
Crashtest
Redaktion
☆☆☆☆☆☆
http://www.microsoft.com/downloads/...FamilyID=766a6af7-ec73-40ff-b072-9112bab119c2
da sind doch die VC_REDIST.EXEn Version 8.0.50727.4053, 28.07.2009 ist noch nich ganz ein Monat her
gibts in x86, x64 und ia64 für Windows 2000,XP,Srv03,Vista,Srv08 einfach saugen und installieren
da sind doch die VC_REDIST.EXEn Version 8.0.50727.4053, 28.07.2009 ist noch nich ganz ein Monat her
gibts in x86, x64 und ia64 für Windows 2000,XP,Srv03,Vista,Srv08 einfach saugen und installieren
Zuletzt bearbeitet:
Devastators
Grand Admiral Special
http://www.microsoft.com/downloads/...FamilyID=766a6af7-ec73-40ff-b072-9112bab119c2
da sind doch die VC_REDIST.EXEn Version 8.0.50727.4053, 28.07.2009 ist noch nich ganz ein Monat her
gibts in x86, x64 und ia64 für Windows 2000,XP,Srv03,Vista,Srv08 einfach saugen und installieren
Also entweder bin ich zu blöd, oder man braucht ein installiertes VS2005 um die Updates zu installieren.
Ich hab das (? ich hab einiges ausprobiert) Teil ja nicht auf einem Client installiert bekommen.
Es kam die Fehlermeldung, dass das zu Updatende Programm (halt VS2005) nicht installiert ist
Ich werde dies aber nochmal explizit ausprobieren.
Ray
Grand Admiral Special
Nicht nur die MFC umstellen.So, es ist Montag Morgen, das ganze WE hab ich mich schon drauf gefreut
Build mit statischen Runtime Libraries
Da tu ich mich noch ein wenig schwer, da ich damit noch nie rumgespielt habe.
Ich habe in den Projekteinstellungen die "Verwendung von MFC" auf statisch gestellt, konnte dann aber nicht weiter linken.
Gut 20 (Microsoft-) Funktionen meldet der Linker als bereits in der msvcr80.dll gefunden.
Als "öffentliche DLL" meckert er ein Teil meiner eigenen Funktionen an, sowie zuletzt die gwmain
Du mußt auch noch unter Codegeneration bei Runtime Library das Richtige einstellen.
Da steht bei Dir garantiert noch xxxDLL!
Devastators
Grand Admiral Special
http://www.microsoft.com/downloads/...FamilyID=766a6af7-ec73-40ff-b072-9112bab119c2
da sind doch die VC_REDIST.EXEn Version 8.0.50727.4053, 28.07.2009 ist noch nich ganz ein Monat her
gibts in x86, x64 und ia64 für Windows 2000,XP,Srv03,Vista,Srv08 einfach saugen und installieren
danke, das scheint die dlls zu installieren.
Ich hätte mir den von Dir gelinkten Thread mal genauer durchlesen sollen
Aber anders gefragt:
Wie komm ich mit der Suche selber auf dieses Package? Ich habe auf der MS Homepage ja schon versucht ein (bzw. das) Redistributable Package zu finden
@Ray
Ich muss zugeben, ich habe mit diesen Einstellungen noch nie etwas zu tun gehabt
Unter Codegenerierung -> Laufzeitbibliothek steht es noch auf Multithreaded-DLL.
Nur Multithraded (/MT) bringt keine Besserung.
Ray
Grand Admiral Special
@Ray
Ich muss zugeben, ich habe mit diesen Einstellungen noch nie etwas zu tun gehabt
Unter Codegenerierung -> Laufzeitbibliothek steht es noch auf Multithreaded-DLL.
Nur Multithraded (/MT) bringt keine Besserung.
Das kann nicht sein. Ein mit komplett auf statische Bibliotheken übersetztes und gelinktes
Programm hat bis auf die rein Windows-spezifischen DLLs (Kernel32.dll usw) keine Abhängigkeiten zu irgendwelchen mit dem Compiler gelieferten DLLs.
(Für C++/MFC/ C Programme).
Eventuell auch ein Release/Debug Problem?
Du musst die Einstellungen jeweils für Debug- und Release vornehmen.
Und natürlich jeweils einen kompletten ReBuild machen.
