Mehrere Prozesse nacheinander in C# ablaufen lassen

Läubi .. schrieb:
> Und was ist mit der "UserToStupidToReportErrorException"... ?
> Ich denke die genaue Fehlermeldung+Stacktrace könnte schon zur Lösung
> beitragen ;)
> Ebenso wie du die Klasse aufrufst...

Aufruf:

1

            string parameter = "-i " + "\"" + GlobalerName + 

2

                "\"" + " -target dvd -y -b " + Convert.ToString(vbitrate)

3

                + "k " + exportpath + "tobeconverted.mpg";

4

            string dateiname = exportpath + "tobeconverted.mpg";

5

6

            // Mpeg in DVD-kompatible Größe schrumpfen

7

            StartProcess("ffmpeg", parameter);

8

            StartProcess("dvdauthor", "-v 4:3,720xfull -t -f " + exportpath + "tobeconverted.mpg  -o "+ exportpath + "temp");

Wenn ich den ersten Prozess ("ffmpeg") auskommentiere, funktioniert der 
Aufruf des zweiten problemlos.
Deswegen habe ich die "StartProcess" im Verdacht (und gepostet).

Wenn ich den Debugger laufen lasse, meckert er an einer anderen Stelle 
rum, un bei den zigtausend Meldungen von ffmpeg zieht sich der ganze 
Kram dann noch mehr in die Länge.

>Fehlermeldung+Stacktrace
Das, was im Bericht für Microsoft steht? Guck beim nächsten Absturz.

So geht's:

1

        private void StartProcess(string ProcName, string Arguments)

2

        {

3

            ProcessStartInfo psi = new ProcessStartInfo(ProcName, Arguments);

4

            psi.RedirectStandardError = true;

5

            psi.RedirectStandardOutput = false;

6

            psi.UseShellExecute = false;

7

            psi.CreateNoWindow = true;

8

            Process p = new Process();

9

10

            //p.OutputDataReceived +=

11

            p.ErrorDataReceived +=

12

                new DataReceivedEventHandler(p_OutputDataReceived);

13

            p.StartInfo = psi;

14

            p.Start();

15

            p.BeginErrorReadLine();

16

17

            p.WaitForExit();

18

            p.ErrorDataReceived -=

19

                new DataReceivedEventHandler(p_OutputDataReceived);

20

            p.Close();

21

22

        }

Vermutlich könnte ich auch mit "Dispose" arbeiten.

Daran lag es gar nicht.
Die "NullReferenceExeption" tritt erst in dem Moment auf, wenn die Daten 
des stdError-Streams in ein Textfeld geschrieben werden sollten.
Wenn der Prozess endete, wurde der EventHandler noch ein Mal aufgerufen.
Da ist das Objekt aber schon NULL...

Der Ablauf funktioniert also nun problemlos auf meinem Rechner.
Auf einem Zielrechner schmiert das Programm aber regelmäßig ab.
Woran kann das liegen?
Auf beiden Rechnern ist das gleiche .NET-Framework instlliert.
Kann mir da jemand eine Antwort geben? Ich wüsst enicht mal, wonach ich 
soll.
Danke im Vorraus!

Hatte ich schon erwähnt, dass genau dieses Problem gelöst ist?
Ich frage inzwischen ab, ob das Objekt NULL ist.

>Schau mal wo dein Objekt Null ist und geh im Debugger durch warum.
Ich habe mir das mal mit dem Debugger angeguckt, aber irgendwie hat der 
die Anweisungen alle ignoriert.
Den StackTrace in eine Datei zu schreiben, war dann die Rettung.

Da scheinbar niemand die andere Frage liest, stelle ich sie hier noch 
mal:
Auf meinem Entwicklungsrechner funktioniert das Programm wie gewünscht, 
auf einem Zielrechner leider nicht.
Woran kann das liegen?
Auf beiden Rechnern ist das geiche .NET-Framwork installiert.

Naja, Du verlässt Dich drauf, dass das p_OutputDataReceived Handling vor 
dem Main Thread fertig ist. Eventuell solltest Du den Main Thread mit 
einem AutoResetEvent blockieren, welches Du in der Handler Methode 
freigibst. Ich kann das Problem nicht nachvollziehen und Dir daher nur 
"Cloud" Tips geben ;-).

Da ich scheinbar noch nicht in der Lage bin, qualifiziert eine Frage zu 
stellen, packe ich hier einfach mal funktionsfähigen Quellcode rein.

Es liegt definitiv nicht an meinem Programm, da ein Test an 
verschiedenen anderen Computern ergeben hat, dass es wie gewünscht 
funktioniert.
Jetzt heisst es also: Programm richtig hübsch machen und Zielrechner für 
das Programm anpassen.

Übrigens kam der heutige/gestrige Betabetrieb bei den Benutzern sehr gut 
an.

Evtl. je nach Anwenderkreis noch beachten: 
http://www.golem.de/1009/77825.html

bluppdidupp schrieb:
> Evtl. je nach Anwenderkreis noch beachten:
> http://www.golem.de/1009/77825.html

Genau an dieser Problematik lag es:
Die auszuführenden Dateien und ihre DLL müssen alle mit im gleich 
Verzeichnis liegen, sofern sie nicht in der PATH-Systemvaribalen 
eingerichtet sind. Das waren sie malo, bis jemand den Rechner 
neugestartet hat...