Problem mit Kompilieren von Programmen.

Question

Hallo Leute,

ich hab mir gerade die Microsoft Visual Studio Express 2013 Version runtergeladen.
Dann wollte ich eine einfache Konsolenanwendung starten, dabei bekomme ich aber folgenden Fehler:

"Console.exe" (Win32): "D:\Eigene Dateien\Visual Studio 2013\Projects\Console\Debug\Console.exe" geladen. Symbole wurden geladen.
"Console.exe" (Win32): "C:\Windows\SysWOW64\ntdll.dll" geladen. PDB-Datei wurde nicht gefunden oder konnte nicht geöffnet werden.
"Console.exe" (Win32): "C:\Windows\SysWOW64\kernel32.dll" geladen. PDB-Datei wurde nicht gefunden oder konnte nicht geöffnet werden.
"Console.exe" (Win32): "C:\Windows\SysWOW64\KernelBase.dll" geladen. PDB-Datei wurde nicht gefunden oder konnte nicht geöffnet werden.
"Console.exe" (Win32): "C:\Windows\SysWOW64\msvcr120d.dll" geladen. PDB-Datei wurde nicht gefunden oder konnte nicht geöffnet werden.
Das Programm "[5156] Console.exe" wurde mit Code 0 (0x0) beendet.

Dies bekomme ich bei jedem Programm, was ich starten will. Ich hab auch schon in dem Ordner geguckt, ob die Dateien überhaupt existieren. Komischerweise existieren sie aber.
Habt ihr irgendwelche Lösungsvorschläge ?

Answer 1

Hallo Felix,

dabei handelt es sich um keinen Fehler sondern nur einen Hinweis, siehe
Gewusst wie: Verwenden des Fensters "Module"

und dort den Abschnitt "Laden von Symbolen" und bei Interesse die dortigen Folgelinks.

Gruß Elmar

Answer 2

Das sind alles DLLs von Microsoft. Damit das nicht passiert, könntest du die PDB Dateien von Microsoft runterladen. Worin allerdings der Sinn liegt, wenn der Debugger die Symbole finden kann, habe ich noch nicht rausgefunden... die DLLs von Microsoft will ich ja sowieso nicht debuggen, also kann der Debugger die Symbole auch gleich ungeladen lassen... wenn ich ein Programm von mir und eine DLL von mir debugge, dann will ich natürlich, dass er die PDB der DLL finden kann (und manchmal findet sie VS einfach nicht) ... in dem Fall -> Rechtsklick auf die DLL (im Fenster Module) und die Symbole manuell nachladen (oder alternativ den Pfad in der Symbol-Pfad-Liste eintragen... aber, auch dann findet VS die Symbole nur in 80% der Debug-Sessions... wieso? keine Ahnung... ich nehme an, weil noch nicht genug Leute das als Fehler bei MS gemeldet haben :-) ).

Also, für deinen Fall hier jetzt ganz konkret -> ignorieren

Gruss,

Rudolf

Answer 3

Es macht sehr wohl Sinn, die Symbole zu kennen und damit, das Layout der Funktionen auf dem Stack. Dadruch lassen sich wenigstens Stacktraces auch durch Windows Callbacks hindruch verfolgen.

Insofern ist Dein Rat: Ignorieren falsch, wenn man tiefgreifender debuggen will.

Richtig ware: Symvbolserver richtig einstellen.

---

Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de

Answer 4

Ja... aber ich hab's jetzt noch nie gebraucht... auch bei Callbacks nicht. Und meiner Meinung nach ist der Aufwand grösser als der Nutzen... zudem (ich will damit jetzt niemandem auf die Füsse treten) dachte ich mir, wenn so eine Frage gestellt wird, dann muss man die Leute nicht mit unnötig komplizierten Verfahren verwirren... es ist noch genug früh, wenn er sich das vornimmt beim Entwickeln von richtig komplexen Sachen wie Treiber oder was weiss ich...

Es war also eine etwas Kontext-bezogene Antwort...

Answer 5

Das hat nichts mit "komplex" zu tun. Just my 2 Cents.

Wenn man simpel schon eine WndProc debugged, kann man eben nicht alle aufrufenden Level sehen, wenn nicht alle Symboldateien geladen werden.
Ohne diese Dateien kann ich keinen Crashdump analysieren und auch nichts vernünftig Debuggen, außer den simplen Sachen....

Also sehe ich es am einfachsten, den Symbolsever richtig einzurichten. In den letzten Versionen von VS, war dies ja schon immer sogar vorgegeben.

Just my 2 cents.

---

Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de

Answer 6

**************************************************************************************************
Dieser Thread wurde mangels weiterer Beteiligung des Fragestellenden ohne bestätigte Lösung abgeschlossen.
Neue Rückfragen oder Ergänzungen zu diesem Thread bleiben weiterhin möglich.
**************************************************************************************************

---

Ionut Duma, MICROSOFT   Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip„Entwickler helfen Entwickler“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.