Evtl. Thread-Problem (Achtung viel Text)

Hi!

Ich habe ein Problem, für das ich schon länger eine Lösung suche, meine Vermutung ist, daß es sich dabei um ein Threading-Problem handelt. Das ist wie gesagt aber nur eine Vermutung, deshalb suche ich Hilfe, wie man das Problem näher eingrenzen kann.

Meine Anwendung läßt sich problemlos komilieren, ausführen und beenden. Wenn ich dann in einem Teilprojekt eine Änderung mache, kann ich diese Assembly nicht mehr kompilieren, ich bekomme den Compiler-Fehler:

Fehler 130 Datei obj\Debug\assembly1.dll kann nicht in ....\output\assembly1.dll kopiert werden. Der Prozess kann nicht auf die Datei ....\output\assembly1.dll zugreifen, da sie von einem anderen Prozess verwendet wird.

Da dieser Fehler immer nur dann auftritt, wenn ich die Anwendung vorher im VisualStudio gestartet habe vermute ich, daß die DLL noch von der Anwendung benutzt wird, und diese (bzw. Reste davon) immernoch irgendwo im Speicher liegen. Der entsprechende Prozess "testprogramm.vshost.exe" ist auch immernoch im TaskManager sichtbar und läßt sich nicht beenden.

Da ich mehrere Threads verwende, nehme ich nun an, daß irgendein Thread nicht ordnungsgemäß beendet wurde. Ich hab also das Programm debuggt, indem ich mir per Debug/Fenster/Threads die aktiven Threads anzeigen lassen habe. Tatsächlich waren auch beim Beenden der Anwendung noch mehrere Threads aktiv. Bezeichnenderweise auch einer davon in der Zeile, wo die Form.Invoke-Methode aufgerufen wird.

Ich hab das Programm soweit optimiert, daß nun beim Beenden keine weiteren Threads mehr aktiv sind, also gehe ich davon aus, daß alle Threads ordnungsgemäß beendet wurden. Trotzdem kann ich die Assemblys nach einer Änderung nicht wieder kompilieren, das Problem hat sich also nicht geändert.

Wer hat einen Tip für mich, wie ich die Anwendung debuggen kann, um dem Fehler auf die Spur zu kommen?

Vielen Dank schonmal,
Christian

Probiers über Ctrl+F5, also "Start Without Debugging"; ob's so klappt....

Bringt leider auch nichts...

Hallo MrSparkle,

teste mal, was passiert, wenn du die Anwendung mit Environment.Exit verlässt.

herbivore

Hi herbivore,

halt leider nicht geklappt:

	static class Program
	{
		/// <summary>
		/// Der Haupteinstiegspunkt für die Anwendung.
		/// </summary>
		[STAThread]
		static void Main()
		{
			Application.EnableVisualStyles();
			Application.SetCompatibleTextRenderingDefault(false);
			Application.Run(new Form2());
			Environment.Exit(0);
		}

Original von MrSparkle
Der entsprechende Prozess "testprogramm.vshost.exe" ist auch immernoch im TaskManager sichtbar und läßt sich nicht beenden.

Hallo MrSparkle

Testhalber würd ich mal das...

Deaktivieren des Hostprozesses

ausprobieren.

Gruss
wakestar

Hast du vielleicht bei der Refernz von assembly1.dll auf die Eigenschaft "Local Copy" auf True gesetzt?

Hi,

danke für die Tips!

Hast du vielleicht bei der Refernz von assembly1.dll auf die Eigenschaft "Local Copy" auf True gesetzt?

Ja, hab ich. Aber auch wenn ich die Eigenschaft auf "false" setze, alles neu erstelle und das Programm starte, kann ich es hinterher nichtmehr kompilieren. Die Fehlermeldung ist die gleiche.

Testhalber würd ich mal das...
Deaktivieren des Hostprozesses
ausprobieren.

Hab ich ausprobiert und es scheint zu funktionieren. Keine Fehlermeldungen mehr beim Kompilieren.
Aber was sagt mir das jetzt? Ich nehme dan, daß der "Host-Prozess" die xxx.svhost.exe ist, die nicht beendet wird. Das eigentliche Problem ist ja damit noch nicht gelöst, oder? Kannst du mir da noch einen Tip geben?

Schöne Grüße,
Christian

Ich tippe mal auf mehrfaches "Copy Local ". Das sollte ausschließlich für bei Referenzen auf true gesetzt werden, die nicht Teil der Solution sind - also via "Add Reference/Browse" hinzugefügt wurden. Ausnahme sind GAC-Assemblies.

Typischerweise entsteht das Problem, wenn man mehrere Projekte in ein Output-Verzeichnis schubsen will (scheint bei dir der Fall zu sein). Kein gutes Vorgehen bei VS und .NET.

Wenn Svensons Tip (mehrfaches Copy Local) auch nicht zutrifft, dann ist es IMHO ein VS Bug. Der Hostprozess arbeitet ja sobald du einmal deine Appliaktion im VS gestartet hast... damit eben die (im Link genannten) "Debugging-Features" zur Verfügung stehen.
Die Frage ist nun, ob Du auch ohne diese Features leben kannst (für dieses Projekt).

Ansonsten mit Sysinternals - Tools die Filezugriffe des Hostprozesses mitverfolgen, villeicht siehst Du dort was wann wie oft gemacht wird.

Hi!

Meine Solution besteht lediglich aus zwei Projekten. Eins davon ist eine Assembly mit einem Control, das mit den verschiedenen Threads arbeitet. Das andere ist die Test-Anwendung. Es wird also nur die erstere Assembly vom Testprogramm referenziert, dabei macht es offentlichtlich keinen Unterschied, ob ich Local Copy auf true oder false setze.

Wenn ich den Hostprozess für das Test-Programm deaktiviere, scheint es ja zu funktionieren, aber ich kann ja nicht von den Anwendern des Controls verlangen, daß sie auch ihren Hostprozess für die entsprechende Anwendung deaktivieren. Deshalb wäre eine Lösung des eigentlichen Problems das was ich anstreben würde.

Meine erste Vermutung (daß noch Teile der Anwendung bzw. irgendein Thread nach dem Beenden im Speicher sein Unwesen treibt), habt ihr gar nicht aufgegriffen. Darf ich deshalb annehmen, daß das nicht der Fall sein kann? Zumal wenn ich das Programm mit Environment.Exit() beende?

Und noch eine Merkwürdigkeit ist mir aufgefallen: Die gesperrte DLL kann ich auch nicht mit dem Unlocker-Tool freigeben, das in einem anderen Beitrag erwähnt wurde.

Wenn es ein Bug vom VS wäre, müßte man doch darüber irgendetwas lesen können, oder?

Sysinternals kenne ich (noch) nicht, wie könnte ich denn die Ausgabe interpretieren, um herauszufinden, was das Problem verursacht?

Schöne Grüße,
Christian

Aufgrund des bisher geschriebenen würde ich wetten dass die Ursache nicht deine Anwendung sondern der Hostprozess ist.

Hier gibt es was zu diesem Thema:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=90699

Kannst Du allenfalls auf einem anderen PC die VS - Express - Edition installieren und dort dein Control einbinden und schauen ob der Fehler auch kommt? Es könnte an deiner lokal installierten Version und Einstellungen des VS liegen.

Betr. Sysinternals: Nimm dir mal die Zeit, diese Tools anzuschauen. - Sie können sehr hilfreich sein... nicht nur bei diesem Problem hier.
Im konkreten Fall würde ich mit dem Filemonitor den *.vshost.exe Prozess tracen und dann zeigt das Tool was alles abgeht

edit: typos

Hi wakestar!

Hier gibt es was zu diesem Thema:

>

Ja, leider ist der Beitrag geschlossen wegen nicht reproduzierbar gg
Das gibt mir nicht besonders viel Hoffnung... 🙁

Kannst Du allenfalls auf einem anderen PC die VS - Express - Edition installieren und dort dein Control einbinden und schauen ob der Fehler auch kommt? Es könnte an deiner lokal installierten Version und Einstellungen des VS liegen.

Auf Arbeit hab ich auch die Professional-Version installiert, da gibt es selbstverständlich die gleichen Probleme. Allerdings hab ich das noch nicht so genau durchprobiert, da ich diese Woche erst wieder am Donnerstag im Büro bin. Dachte, ich kann mich in der Zwischenzeit mit diesem Problem beschäftigen...

Betr. Sysinternals: Nimm dir mal die Zeit, diese Tools anzuschauen. - Sie können sehr hilfreich sein... nicht nur bei diesem Problem hier.
Im konkreten Fall würde ich mit dem Filemonitor den *.vshost.exe Prozess tracen und dann zeigt das Tool was alles abgeht

Die Ausgabe ist leider nicht besonders aufschlußreich. Außer auf die Datei "TestProgramm.VSHOST.EXE" (auch mit den Suffixen ".config", ".manifest", und ".Local") selbst erfolgen nur noch Zugriffe auf diese Datei:
"C:\WINDOWS\Prefetch\TestProgramm.VSHOST.EXE-29EDC3C0.pf"

Aber mal ne ganz andere Frage: Was müßte denn normalerweise mit dem Host-Prozess passieren, wenn man das Programm beendet hat? Es sollte doch aus der Liste im Taskmanager verschwinden, schätze ich mal. Da es nicht verschwindet (und sich auch nicht "abschießen" läßt) bin ich immer davon ausgegangen, daß mein Programm nicht ordnungsgemäß beendet wurde.

Schöne Grüße,
Christian

Na endlich jemand, der das selbe problem wie ich hatt!

Ich habe zwei Lösungen gefunden (beide nicht schön):

1. VisualStudio beenden, bin-Verzeichnisse leeren, VisualStudio starten... klappt meistens, aber ist sehr Zeitintensiv

2. In den Projekt-Settings einfach den Ausgabepfad ändern (aus Debug wird Debug2). Klappt auch meistens, aber erzeugt halt eine menge unötige Dateien auf der Platte

Original von MrSparkle
Aber mal ne ganz andere Frage: Was müßte denn normalerweise mit dem Host-Prozess passieren, wenn man das Programm beendet hat? Es sollte doch aus der Liste im Taskmanager verschwinden, schätze ich mal. Da es nicht verschwindet (und sich auch nicht "abschießen" läßt) bin ich immer davon ausgegangen, daß mein Programm nicht ordnungsgemäß beendet wurde.

Nein, das ist das normale Verhalten des Hostprozesses.
Hostprozess

Der Hostprozess ist ein Feature in Visual Studio 2005, das die Debugleistung verbessert sowie das Debuggen von teilweise vertrauenswürdigen Anwendungen und die Ausdrucksauswertung zur **Entwurfszeit **ermöglicht.

Original von MrSparkle
Ja, leider ist der Beitrag geschlossen wegen nicht reproduzierbar gg
Das gibt mir nicht besonders viel Hoffnung... 🙁

dort hat es immerhin 5 "Workarounds" 😁

Hi!

1. VisualStudio beenden, bin-Verzeichnisse leeren, VisualStudio starten... klappt meistens, aber ist sehr Zeitintensiv

Bei mir reicht es, VS neuzustarten. Ist aber nicht gerade schön, weil ja alle Undo-Schritte dabei verlorengehen. Und überhaupt ist es umständlich.

2. In den Projekt-Settings einfach den Ausgabepfad ändern (aus Debug wird Debug2). Klappt auch meistens, aber erzeugt halt eine menge unötige Dateien auf der Platte

Muß ich ja auch jedesmal ändern, da ist das Neustarten noch einfacher...

Darf ich fragen, um was für ein Projekt es sich bei dir handelt? Oder hast du das Problem bei verschiedenen Projekten? Hast du schon ein bißchen rumprobiert, und evtl. was rausfinden können?

dort hat es immerhin 5 "Workarounds"

Vielleicht bin ich mit Blindheit geschlagen (wäre auch kein gutes Zeichen), aber ich kann nur einen Workaround erkennen: "The only work around that works for me is to kill the vshost process then debug."
Das geht aber bei mir nicht, ich kann den Prozess wie gesagt nicht killen...

Letztendlich muß es ja ein Workaround sein, den man den Benutzern des Controls zumuten kann. Wenn meine Kollegen das Control in der Anwendung verwenden, und müssen jedesmal den Ausgabepfad ändern oder VS neu starten, werden sie mich nicht gerade mit großer Dankbarkeit überhäufen...

Schöne Grüße,
Christian

Original von MrSparkle
Vielleicht bin ich mit Blindheit geschlagen (wäre auch kein gutes Zeichen), aber ich kann nur einen Workaround erkennen: "The only work around that works for me is to kill the vshost process then debug."

Ok, ist villeicht nicht sehr offensichtlich....

• guckst du oben rechts in dokument
• guckst du unter "workarounds"
• klickst du auf "View"
• machst du lesen dokument

Ok vielen Dank! 🙂 Es ist halt wirklich sehr versteckt ganz oben auf der Seite in fett und 14pt-Schrift :b Aber dank deiner ausführlichen Anleitung hab ich es nun doch gefunden.

Eh ich mich nochmal blamiere, hab ich jetzt eine Weile rumprobiert. Das Ergebnis ist kurz zusammengefaßt: Es geht nicht. Sobald ich das Projekt neu kompiliere, kommt der Fehler, egal ob ich eine neue Instanz starte oder irgendetwas anderes. Ohne vorher zu kompilieren ist ja nichts da, was man starten kann.

Dabei hab ich allerdings festgestellt, daß ich das Projekt nichtmal starten muß, um den Fehler zu reproduzieren. Einfach zweimal nacheinander "Neu Erstellen" klicken, und schon hab ich den Fehler. Kann man evtl. dadurch das Problem enger eingrenzen?

Interessant fand ich dagegen den Hinweis auf den Settings-Designer. Den benutze ich zwar nicht und hab die vorhandene Settings-Datei vorsichtshalber mal gelöscht. Aber ich benutze einige Resourcen im Control (Skriptdateien bzw. Shader, Bitmaps etc.) die evtl. das gleiche Verhalten haben. Leider geht der Autor des Workarounds nicht genauer darauf ein, wie der Fehler durch den Settings-Designer ausgelöst wird. Deshalb hab ich wohl erstmal keine andere Wahl, als die Resourcen zu entfernen und es dann nochmal auszuprobieren. Leider muß ich dazu viel am Code ändern, so daß ich viel Arbeit damit haben werde und nichtmal weiß ob sich das lohnt.

Schöne Grüße,
Christian

Schau mal hier:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=866645&SiteID=1

Cheng Wang

Hi there,

I just fix the same problem, but it is a long story, so hope u donot get bored.

My solution have about 10 projects, the core project use all the others. After some operation to SVN, I cannot build my core project but all the other are ok.

I use task manager find that once i load the solution, the core project's xxx.vshost.exe is running. and it restart after manually kill the task. then i look into my project, some usercontrols and forms cannot be open with designer, so here are the operations i fix this first. u may have one or all of them 🙂

1. In a usercontrol class's  .resx file , i find a automatically generated XML code for one of the  properties i defined in .cs file. it is designed for get info at runtime. however, the IDE properties try to read it at design time, so it fail to load the usercontrol.    

i delete the associated xml code from .resx, and it works well now.

2. similarly, in the On_paint funtion of my usercontrol, i use a runtime class reference. so at the design time, when IDE load and try to show the usercontrol, and fail.  

so i put a try{} cath{} to go around this, and it works well now.

after fix this two problems. the xxx.vshost.exe stop running. then my solution recovered from the error of

"Unable to copy file ..... "

I think the error is caused by the running xxx.host.exe, it occupies the .dll files so they cannot be replaced at the building time.

Original von MrSparkle
Hi!

1. VisualStudio beenden, bin-Verzeichnisse leeren, VisualStudio starten... klappt meistens, aber ist sehr Zeitintensiv

Bei mir reicht es, VS neuzustarten. Ist aber nicht gerade schön, weil ja alle Undo-Schritte dabei verlorengehen. Und überhaupt ist es umständlich.

Ahaha... bei mir dauert der Neustart knappe 15 Minuten....

Darf ich fragen, um was für ein Projekt es sich bei dir handelt? Oder hast du das Problem bei verschiedenen Projekten? Hast du schon ein bißchen rumprobiert, und evtl. was rausfinden können?

Ein recht große Solution mit etlichen (>20) Projekten...
Und das Problem kenne ich auch nur von diesem einem Projekt bei mir....

Vielen Dank svenson, jetzt weiß ich wenigstens, daß ich auf dem richtigen Weg bin.

Ich hab jetzt die Resourcendateien aus dem Projekt entfernt. Bim Kompilieren kommt ein Fehler, der im Constructor des Controls ausgelöst wird, wenn er die Resourcen laden möchte (TypeInitializationException).

Wenn das aufgetreten wäre, wenn der Formular-Designer offen ist, hätte es mich nicht gewundert, da er ja tatsächlich eine Instanz des Controls erzeugen muß. Aber das passiert auch so. Also scheinen die Resourcen-Dateien irgendwie mit dem ursprünglichen Fehler zusammenzuhängen.

Da ich auf die Resourcen nicht verzichten kann (es sind lebensnotwendige Dateien), würde ich erstmal versuchen herauszufinden, warum der Constructor beim Kompilieren aufgerufen wird. Ich hätte die TypeInitializationException eigentlich nur zur Laufzeit erwartet, nicht beim Kompilieren.

Irgendwie kann ich für das alles kein Verständnis aufbringen...

Schöne Grüße,
Christian

@cadi

Ahaha... bei mir dauert der Neustart knappe 15 Minuten....

Das ist ein ganz anderes Problem. Bei meinem Kollegen dauert es ungefähr genausolange, bei mir nur ein paar Sekunden. Wenn die Dateien noch irgendwo im Cache liegen, dann ist es sozusagen sofort wieder da.

Ein recht große Solution mit etlichen (>20) Projekten...
Und das Problem kenne ich auch nur von diesem einem Projekt bei mir....

Kannst du da das Problem mit den Resourcendateien nachvollziehen? Oder mit der Settings-Datei?

Schöne Grüße,
Christian

Was passiert denn, wenn du das Control-Projekt rausnimmst und im Testprojekt die Dll über den Pfad referenzierst?

Original von svenson
Was passiert denn, wenn du das Control-Projekt rausnimmst und im Testprojekt die Dll über den Pfad referenzierst?

Dann funktioniert es, da ich ja die Control-Assembly nicht neu erstellen muß. Der Fehler tritt überhaupt nur auf, wenn ich Änderungen im Code des Controls gemacht habe. Wenn ich nur das Test-Projekt editiere, kompiliert er es neu, indem er auf die vorhandene DLL verweist.

das würde aber bedeuten dass die Anwender deines Controls kein Problem haben werden.... oder bin ich jetzt falsch???

Ok.
Merkwürdiges Problem -> Merkwürdige Lösung!

Ich habe nun folgendes gemacht. In der Assembly befindet sich wie gesagt ein UserControl. Dieses hat eine resx-Datei, in der lediglich die Positionen der beinhalteten Steuerelemente gespeichert sind. Die sind nicht wichtig, deshalb hab ich einfach alle Einträge gelöscht.

Jetzt kann ich das Projekt wieder wunderbar kompilieren und re-kompilieren usw. usf.

Ob das jetzt die eigentliche Ursache war, und wie das alles zusammenhängt, kann ich im Moment nicht sagen. Ich hoffe, es hat sich jedenfalls erstmal erledigt. Falls nicht, melde ich mich wieder 😉

Ich danke euch für eure vielen und kompetenten Beiträge!!

Christian

// Edit:

das würde aber bedeuten dass die Anwender deines Controls kein Problem haben werden.... oder bin ich jetzt falsch???

Nein, jedenfalls nicht solange sie nicht das Control bearbeiten, was meine Kollegen aber machen könnten. Soweit hatte ich aber gar nicht gedacht, ich wollte das eigentliche Problem ausfindig machen. Wenn es tatsächlich ein Thread-Problem oder sowas gewesen wäre, hätte das andere Probleme verursachen können, was ich in erster Linie vermeiden wollte.

Original von MrSparkle
Nein, jedenfalls nicht solange sie nicht das Control bearbeiten, was meine Kollegen aber machen könnten.

Schreib doch einleitend ein Kommentar im Source-Code: "Achtung, wer hier was ändert, bekommt es allenfalls mit dem vshost.exe zu tun!" 😉

...oder ich geb den Quellcode einfach nicht frei 🙂

Hallo,

ich hatte vor einiger Zeit einen längeren Beitrag gestartet, weil ich beim Kompilieren meines Projektes immer den folgenden Fehler bekomme:

Fehler 130 Datei obj\Debug\assembly1.dll kann nicht in ....\output\assembly1.dll kopiert werden. Der Prozess kann nicht auf die Datei ....\output\assembly1.dll zugreifen, da sie von einem anderen Prozess verwendet wird.

Ich habe in meiner Solution eine Klassenbibliothek und ein Windows-Programm, das die Klassenbibliothek verwendet. Nachdem ich das Programm mit F5 gestartet hab, kann ich den Quelltext der Klassenbibliothek nicht mehr verändern, da sonst beim nächsten Start oder Kompilieren der o.g. Fehler kommt.

Ich hatte das Problem schon vor einiger Zeit, und konnte es beheben indem ich eine resx-Datei aus einem Steuerelement gelöscht hatte (siehe anderer Beitrag, ganz unten).

Jetzt tritt das Problem wieder auf, nachdem ich eine neue Solution mit einem neuen Programm (aber derselben Klassenbibliothek) angelegt habe. Nun bin ich (wieder einmal) mit meinem Latein am Ende, vielleicht hilft mir der eine oder andere Hinweis, dem Problem diesmal auf den Grund zu kommen...

Danke schonmal!

Schöne Grüße
Christian

Tja irgendein anderer Prozess greift auf Assembly1.dll zu, machst Du vielleicht was mit DLLs suchen in deinem Projekt und öffnest Filehandles?

Oder rufst Du einen Prozess auf? Eine Exe die die DLL auch benutzt?

Bleibt vielleicht eine VSHost.Exe Instanz auf dem File hängen?

Was machst Du denn in deinem Programm?

Fragen über Fragen...
Also der Reihe nach:

machst Du vielleicht was mit DLLs suchen und öffnest Filehandles?

Meinst du Assemblys dynamisch laden? Reflection? Wenn ja, dann nein. Es finden auch keine anderen Zugriffe auf eine DLL statt (außer der projektinterne Verweis)
XML-Dateien werden allerdings über FileStreams geladen, aber die Streams werden ordnungsgemäß geschlossen.

Oder rufst Du einen Prozess auf?

Nein, nicht explizit.

Eine Exe die die DLL auch benutzt?

Keine, außer die Windows-Anwendung im Projekt.

Bleibt vielleicht eine VSHost.Exe Instanz auf dem File hängen?

Ja, solange VS geöffnet ist. Den Prozess kann ich auch im Taskmanager nicht abschießen. Es hilft leider nur, VS zu beenden und neu zu starten, dann kann ich wieder (einmal) kompilieren.

Was machst Du denn in deinem Programm?

In der DLL befindet sich meine 3D-Engine. Die verwendet mehrere Threads (z.B. um Dateien im Hintergrund zu laden), deshalb war meine erste Vermutung, daß es sich um ein Thread-Problem handelt, aber das habe ich ja bereits ausschließen können. In der DLL wird ein Control veröffentlicht, das für die Darstellung der Grafik zuständig ist. In der Anwendung selbst wird das Control verwendet und angesteuert.

Allerdings habe ich keinen Form-Designer offen, der die DLL referenzieren könnte.

Helfen die Angaben weiter?

Schöne Grüße,
Christian