Hallo,
kann es sein, dass Du mit einem Laptop arbeitest?
Wie ist die Auslastung der Festplatte(Festplattenaktivität)?

Meine Frau hatte das auch mal auf einem Laptop.
Schuld war in diesem Fall:
1. Windows hat Updates gezogen und
2. Windows hat die Festplattendateien zum schnelleren Start indiziert.

Na dann scheint es an der Installation von Visual Studio zu liegen.
Hatte so was mal an der Arbeit.
Nach einer Neuinstallation lief dann alles wie geschmiert.

Warum kein aktuelles VS?

@Amelie Ich glaube, an deiner Stelle hätte ich mir schon lange VirtualBox installiert und ein virtuelles Windows 10 hochgezogen auf dem auch ein aktuelles VS lauft.

Also... ich sehe auf dem Bild nichts außergewöhnliches. Dass VS einiges an CPU-Last erzeugt, ist vollkommen normal. dass hier einige MB Arbeitsspeicher reserviert werden, ebenfalls. Anhand dieses Screenshots kann man hier also tatsächlich gar nicht helfen.

Viel interessanter wären hier noch weitere Angaben:
Wenn du schreibst, du hättest keine Möglichkeit, weil Zugriff verweigert: Von was wird dir der Zugriff verweigert? Von VS selbst? Von einem Projekt, das VS zu öffnen versucht? Andere Dienste eventuell? Das wäre interessanter zu wissen.

Dass VS einige Zeit beschäftigt ist, kann durchaus auch normal sein. Wenn VS beim Starten zum Beispiel nach Updates sucht, oder andere Aufgaben beim Starten ausführt, ist es durchaus möglich, dass das Starten von VS eben etwas länger dauert. Dieses kannst du im Grunde nur umgehen, wenn du entsprechende Aufgaben bei VS abstellst. Ob das bei deiner Version geht, weiß ich nicht, da ich mit dem Studio nicht arbeite.

Ich gebe meinen Vorrednern insofern Recht, dass ich ebenfalls empfehlen würde, ein aktuelleres VS zu nutzen. Leider auch hier mit starken Einschränkungen: Meist bedeuten neuere Versionen in den meisten Fällen aber auch mehr Hardwareauslastung, da die Apps eher mehr Funktionen bekommen, statt abgespeckt zu werden. das heißt, wenn dein Setup da schon schwächelt, werden neuere Versionen unter Umständen auch hungriger werden können. Im Umkehrschluss können neuere Versionen aber auch eben Probleme von Vorgängern ausbügeln können, sollte sich an der Grundstruktur etwas stark geändert haben (Optimierungen gibt es eben auch zu hauf). Das ganze in eine virtuelle Box auszulagern kann ebenfalls Probleme mit sich bringen, da auch hier der "Hunger" generell steigt.

Also meine Empfehlung ist, schau erstmal, ob du in VS einige Einstellungen optimieren kannst. Wenn nicht, sollte man sich Gedanken über die Hardware machen. Auch hier kann ich nur sagen: 16 GB RAM, SSD, etc. sind nur pauschale Angaben. Aber dennoch heißt das nicht, dass deshalb alles schnell oder wie geschmiert läuft. Angenommen du hast ein älteres Mainboard (was wir nicht wissen), dann können 16 GB, vor allem wenn sie auf 4x4GB erstreckst sind) das System langsamer werden lassen als zB 1x16GB oder 2x8GB (Je nachdem ob Dual-Channel vorhanden und richtig genutzt). Auch bei einer SSD kann man nicht pauschal sagen, dass alles wie der Blitz läuft. Denn auch hier haben gerade günstigere Mainboards und Hardware-Komponenten eigene Einschränkungen. Wenn zum Beispiel das Speicherinterface der PCI-Lanes auf dem Mainboard nicht stark genug sind, wird man auch hier nicht das Maximum rausholen können. Deshalb finde ich es immer schwierig, Hardware nur anhand solch einfacher Werte zu vergleichen oder für die Analyse heranzunehmen.

Generell empfehle ich auch: Bei Hardwareüberwachungen nicht im Reiter Prozess zu schauen. Hier sind eher wenig Informationen aufgelistet. Der Reiter Leistung zeigt schon deutlich mehr und auch "bessere" Informationen an, die für das System und dessen Auslastung relevant sein könnten - vor allem bei neueren Windows-Versionen ist dieser Reiter noch stärker ausgebaut. Noch besser aber wäre, wenn du beim Starten von VS den "Ressourcenmonitor" geöffnet hast (Befehl: resmon -> Windowstaste + R drücken, in dem "Ausführenfenster" einfach "resmon" eingeben und Enter drücken). Hier hast du eine Übersicht über wirklich viele Hardware-Informationen und sieht auch einzelne Datentransfers von Prozessen und Auslastungen, Fehlerraten, etc. Hier kann man sehr schön sehen, wenn einige Dinge an "ihre Grenzen" kommen.

Ansonsten bleibt meine Aussage leider: Mit den von dir bisher gegebenen Informationen orakeln wir tatsächlich ins Blaue - zumal es bei einer solch komplexen Technik schwierig ist, wirklich den einen Schuldigen ausfindig zu machen

Hallo,

wenn Du bei der Situation von "vs-feler1.jpg" auf nein klickst bricht der Debugging Vorgang ab, und im Fehlerfenster (siehe Bild Fehlerliste) wird ein Fehler angezeigt.
Poste diesen Fehler doch mal.

MfG xmise

Hmm...
Ich schlage vor, dass Du dem Rat von PadreSperanza folgst und mit dem Resourcen Monitor während der Fehler auftritt auf Spurensuche gehst.
Entweder blockt VS die Dateien zu lange oder ein anderer Prozess (vielleicht sogar Schadsoftware) verhindert eine Zeitnahe Freigabe der Dateien.

Da läuft doch noch eine alte Instanz der exe und kann deshalb beim Build nicht überschrieben werden.
Schalte mal von Release auf Debug um, ob das geht.
Oder ob du bei der zweiten Änderung wieder auf Fehler läufst.

Amelie schrieb:

Ich beende das Debugging ja immer mit dem "Rotem Quadrat"

Könnte ein Faktor sein. Das rote Quadrat führt AFAIK ein Hauruck-mach-alles-platt-Beenden durch wie der Befehl End. Daher immer alle Forms auf regulärem Weg beenden.

Amelie schrieb:

Lasse Wöchentlich einen Scanner laufen. Bisher immer ohne Vieren, Trojaner etc.

Naja bei einem Betriebssystem das End of Life ist und keine Security Updates mehr bekommt kann es durchaus auch Sicherheitslücken geben die kein Scanner dir aufzeigt weil Microsoft diese auch nicht mehr
interessiert. Ich rate dir hier dringend zu einem Upgrade. Alles andere ist leider fahrlässig wenn man mit dem Internet verbunden ist und vor allem auch eventuell Software programmiert die noch
auf anderen Rechnern laufen sollen.

Amelie schrieb:

Ich beende das Debugging ja immer mit dem "Rotem Quadrat"

Du meinst damit den Stop Button?
Das mache ich eigentlich auch und es gibt nie ein Problem.
Deinen Fehler bekomme ich nur, wenn ich das Programm außerhalb der IDE direkt aufrufe und dann versuche, in der IDE neu zu kompilieren.
Bist du sicher, dass da nicht parallel zur IDE eine Instanz der EXE läuft?

Ich denke, wenn ich das nun alles hier richtig sehe und verstehe, ist der Ansatz von zu schwacher Hardware komplett fehl am Platz. Wie ich schon eingangs sagte, sah ich nichts, was da "schlimm" aussah. Dein beschriebener Fehler lässt bei mir ganz andere "Alarmglocken" klingeln...

Ich sehe bei dem Screenshot leider nur den linken Bereich. Den rechten hast du leider abgeschnitten, sodass ich da nicht viel mehr sehe außer, dass versucht wird, eine Datei von obj/..../...exe in bin/.../...exe zu kopieren. Das funktioniert nicht, da du die bin/.../...exe verwendest, solange du dich im Debug befindest. Nicht mehr und nicht weniger sagt diese Fehlermeldung aus. Und das hat hier nichts mit Hardware, Betriebssystem oder anderen Dingen zu tun, sondern da ist eben etwas in der Software, das dieses Verhalten auslöst - Also das Betriebssystem kann durchaus "Schuld" daran sein... aber das nur am Rande.

So wie ich das sehe und lese, scheint es so, als würde versucht werden im laufenden Betrieb eine Datei zu überschreiben, die verwendet wird. Dies kann mehrere Ursachen und das sollten wir erfoschen.
Eine mögliche Ursache könnte sein: Du benutzt tatsächlich einen von dir eingeleiteten Kopiervorgang (also möchtest irgendeine Datei an eine andere Stelle schieben) und hier tritt ein Fehler auf. Wenn man zB einen Update-Prozess schreiben möchte und einfach aus der eigenen App heraus die neuen Dateien in den Pfad kopieren möchte, muss vorher sichergestellt sein, dass der Prozess nicht mehr auf die EXE-Datei zugreift, da sonst ein Kopieren nicht möglich ist. Trifft hier sowas zu bei dir?

Nächste Überlegung: Benutzt du irgendwelche Streams in jedweder Form, die auf andere Daten, Datensätze, Programme oder dergleichen zugreifen, die mittels ​.Close() geschlossen werden müss(t)en?
Häufig passiert es, dass man zB FileStreams nutzt (zB File.Create(...)) und vergisst, dass hierbei ein Stream entsteht, der eine "Verbindung" zu dieser Datei aufbaut. Wird dieser Stream nicht wieder geschlossen und das Programm beendet, bleibt für das OS (also Windows) diese Verbindung aktiv, auch wenn eine Seite dieser Verbindung - nämlich die App selbst - gar nicht mehr da ist und von der Verbindung nichts mehr weiß. Auch wenn du die App wieder startest, erinnert sie sich nicht an die alte Verbindung, sondern versucht, eine neue aufzubauen. Da in solch einem Fall aber die Verbindung bereits zu einer anderen Stelle existent ist, erhältst du einen Fehler, da der Zugriff bereits von einem anderen Prozess blockiert wird.
Kann es also sein, dass du irgendwo vergessen hast, .Close() aufzurufen und damit eine Blockade schaffst?
Üblicherweise wird so etwas schnell vergessen wenn man in einem Try-Catch-Block unterwegs ist. Hier sollte (oder gar muss?) immer im Finally-Block die Verbindung aufgehoben werden, sollte sie existieren, um so etwas zu umgehen (oder man nutzt die Using Statements).

Ich stochere nach wie vor im Dunkeln und Trüben herum, da ich nach wie vor nicht all das sehe, was du siehst. Aber meine Vermutung ist stark, dass aus irgendwelchen Gründen deine Zugriffe durch deine eigene Programme blockieren könntest - zumindest liest sich das aus der Fehlermeldung so.

Um also langsam näher an das Ziel zu kommen: Was genau ist der Ordner "obj"? Was soll sich darin befinden und warum? Und warum soll etwas aus diesem Ordner "obj" in "bin" kopiert werden?

Sollte tatsächliche eine Blockade aufgrund des OS anstehen (also gehaltene Verbindung), kannst du das Problem dahingehend temporär beheben, indem du Windows tatsächlich einmal neu startest. Dann werden aktive Verbindungen gelöst und du kannst wieder von vorne starten. Hier bleibt aber dennoch die Recherche schuldig, warum es überhaupt zu solch einer Blockade kommen konnte.

Den Fehler aus post#10 kenne ich auch, und bei uns wissen wir auch nix besseres als VS ausmachen, wieder anmachen, Solution Bereinigen, Solution kompilieren.
Unsere Solution ist auch extrem fett, enthält auch Com-registrierte Projekte, manifest-signierte Projekte, und lizensierte Steuerelement-Bibliotheken von Drittanbietern.
Der angemeckerte Kopier-Vorgang ist auch nicht Teil der Programm-Ausführung, sondern wenn VS das Zeug buildet und im Debugger laufen lassen will, ist der Kopiervorgang offsichtlich erforderlich.
Die Ordner obj\ und bin\ sind Bestandteil jedes Projekts, und werden generiert, wenn ein Testlauf gestartet wird.
Und VS steht sich da manchmal selbst im Weg.
In anderen Worten: Ein Bug.

VS legt ein Verzeichnis an "ProjectAssemblies". Dort sammeln sich diverse Versionen der Exe die man erstellt.
Irgendwann hatte ich mir angewöhnt den Inhalt dort kurz vor dem Rechnerrunterfahren zu löschen und wenn ich
mich recht erinnere dann konnte ich damals dami ein ähnliches Problem wegbekommen.