Hallo zusammen,

Ich habe ein problem mit dem windows 2000 terminal server. User
prozesse bei visual basic 5 bleiben teilweise hängen und andere user
können das programm dann nicht mehr öffnen.
Ich muss jedesmal den prozess im taskmanager beenden.
hättet ihr vieleicht eine Idee was man tun kann, das es nicht mehr
hängen bleibt oder das man es nicht immer aus dem taskmanager löschen muss?

Danke

Wenn bei einem User das VB hängenbleibt, hat er die möglichkeit mit CTRL+BREAK den Debugmodus bzw. das Programm zu beenden. Wenn das Terminal nicht reagiert, kannst du das Programm mit dem Prozess - low (niedriger als normal) starten, so würde es nicht den ganzen Server killen, wenn die Appl. hängen bleibt.
Vielleicht gibt es auch VB Script welche die Task überwachen und dann beenden wenn eine Anwendung lange nicht reagiert - mal google

Dumme frage, was meinst Du mit Low sarten?

grz zer00

den Prozesspriorität auf niederiger als normal

via "START /Priorität Anwendung"

START ["Titel"] [/Dpath] [/i] [/MIN] [/MAX] [/SEPARATE | /SHARED]
[/LOW | /NORMAL | /HIGH | /REALTIME] | /ABOVENORMAL | /BELOWNORMAL]
[/WAIT] [/b] [Befehl/Programm]
[Parameter]

"Titel" Der Titel des neuen Fensters.
Pfad Startverzeichnis.
B Startet Anwendung, ohne ein neues Fenster zu öffnen. Die
Anwendung ignoriert STRG+C. Wenn die Anwendung nicht selbständig
STRG+C überprüft, ist STRG+UNTBR die einzige Möglichkeit, um die
Anwendung abzubrechen.
I Die CMD.EXE beim Aufruf übergebene Umgebung soll die neue
aktuelle Umgebung sein.
MIN Startet das Fenster minimiert.
MAX Startet das Fenster maximiert.
SEPARATE Startet 16-Bit-Windows-Programm in separatem Speicherbereich.
SHARED Startet 16-Bit-Windows-Programm in gemeinsamen Speicherbereich.
LOW Startet Anwendung in IDLE-Prioritätsklasse.
NORMAL Startet Anwendung in der NORMAL-Prioritätsklasse.
HIGH Startet Anwendung in der HIGH-Prioritätsklasse.
REALTIME Startet Anwendung in der REALTIME-Prioritätsklasse.
ABOVENORMAL Startet Anwendung in der ABOVENORMAL-Prioritätsklasse.
BELOWNORMAL Startet Anwendung in der BELOWNORMAL-Prioritätsklasse.
WAIT Startet die Anwendung und wartet auf das Ende.
Befehl/Programm
Wenn ein interner Befehl oder eine Batchdatei verwendet wird,
wird das neue CMD-Fenster mit Parameter /K gestartet.
Das bedeutet, dass das Fenster erhalten bleibt, nachdem der
Befehl ausgeführt wurde.
Wenn dies nicht der Fall ist, wird das Programm entweder
als Anwendung in einem Fenster oder als Konsolenanwendung
gestartet.
Parameter Parameter, die an den Befehl oder das Programm übergeben werden
sollen.


Wenn die Befehlserweiterungen aktiviert sind, wird der Aufruf von externen
Befehlen durch die Befehlszeile oder den START-Befehl folgendermaßen verändert:

Nicht-ausführbare Dateien können durch ihre Zuordnung zu einem Dateityp
einfach durch Eingabe des Namens als Befehl aufgerufen werden (z.B. würde
WORD.DOC die Anwendung starten, die der .DOC-Erweiterung zugeordnet ist).
Weitere Informationen, wie Sie diese Zuordnungen innerhalb eines Befehls-
skripts ändern, finden Sie beim ASSOC- bzw. FTYPE-Befehl.

Wird eine grafische 32-Bit-Anwendung aufgerufen, wartet CMD.EXE nicht auf
das Beenden dieser Anwendung, sondern kehrt sofort zur Eingabeauforderung
zurück. Das gilt NICHT, wenn diese Anwendung aus einem Befehlsskript
heraus aufgerufen wird.

Wenn eine Befehlszeile ausgeführt wird, die mit den Zeichen CMD ohne
Erweiterung oder Pfadname beginnt, wird CMD durch den Wert der
COMSPEC-Variablen ersetzt. Damit wird vermieden, dass man versehentlich
eine andere, ggf. zufällige Version der CMD.EXE verwendet.

Wenn eine Befehlszeile ausgeführt wird, die mit Zeichen beginnt, die keine
Dateierweiterung enthalten, dann verwendet CMD.EXE den Wert der Umgebungs-
variablen PATHEXT, um zu bestimmen, welche Erweiterungen in welcher
Reihenfolge verwendet werden. Der Standardwert für die PATHEXT-Variable
ist:

.COM;.EXE;.BAT;.CMD

Dabei ist die Syntax dieselbe wie in der PATH-Variablen, das heißt, die
einzelnen Einträge werden durch Semikolon getrennt.

Wenn mit dem START-Befehl ein Programm bzw. Befehl aufgerufen wird und keine
entsprechende Dateierweiterung gefunden wird, aber der Name ohne Erweiterung
einem Verzeichnisnamen entspricht, wird der Explorer mit diesem Pfad
aufgerufen. Von der Befehlszeile ausgeführt entspricht das einem CD /D mit
diesem Pfad.

ok, das ist zwar nicht ganz was isch wissen wollte aber auch nett.
Ich möchte wissen was es bringt wenn Du einen Prozess mit einer niedrigen Prioritöt laufen lässt.

grz zer00

ah habe Dich falsch verstanden. Was ich mit low meine ... sorry

Weiss nicht wie dannyyy das Problem genau gemeint hat, wenn er durch das VB am Terminalserver Leistungeinbussen für andere Anwendungen hat, zum Beispiel Office - würde es etwas bringen wenn er den VB Prozess auf em Terminal nach unten setzt, damit sich das Prog nicht den ganzen CPU frisst, wenn es sich killt oder nicht mehr reagiert. Da Teilweise VB im Endlosschleifenmodus im Debugger schon Ressourcen verschlingen kann *fress fress*

Ok
Du willst als der (Problem)-App weniger CPU-Zeit geben, damit das OS noch genug Rechenzeit für andere App's zur verfügung hat.
Aber hat das auch Einfluss auf einen abgestürzten Prozess?

grz zer00

Wäre sicherlich auch via VBScript möglich was zubasteln, welche die Prozesse überwacht, habe folgende Seite bei MS gefunden, welche die VB Befehlebeschreibt
http://msdn.microsoft.com/library/de...32_process.asp

jenach dem wie das VB aufhängt, wenn es durch einen Programmierfehler z.b. endlosschleife oder einer pi berechnung dann kann einbisschen Prozessorzeit flöten gehen und die Anwendung wird als Reagiert nicht angezeigt (selber mal ausprobiert). Kommt immer auf das Problem darauf an ... Naja war ja nur ein gedanke, wenn dadurch die Leistung benachteiltig würde ...

@dannyyy
Wann tritt den dieses Problem im VB auf? Machen die User was spezielles ??
Die Frage ist irgendwie untergegangen

Meinst Du VB oder die Anwendung die der user geschrieben hat?
Übernimmt da nicht der Debugger die Kontrolle?

grz zer00

Ich meine schon eine Anwendung die der user geschireben hat. Ist schon richtig das der Debugger die Kontrolle übernimmt, aber ich kenne das VB 5 wenn man dann den Debugger nicht abwürge mit CTRL+Break an ist das System einwenig beschäftig - natürlich kann man auch den VB task killen. Kann bei den neueren Versionen anderst sein, aber mein VB 5 bleibt hängen bis ich den Debugger mit CTRL+Break abwürge.

Drum hoffe ich dass Dannyyy noch mehr Info's erteilt, wann dieser Crash passiert.

Ich kenne mich mit VB-Studio nicht aus, beziehe mich daher auf Delphi.
Wenn mir da eine App die ich geschrieben habe abschmiert(die App wird aber aus Delphi gestartet) wird der Task an Delphi zurück gegeben und ich kann dann entscheiden ob ich mir noch die CPU-register anschauen möchte, oder wenn möglich in steps das Programm weiter abgearbeitet werden kann.
Um auch Delphi zum absturz zu bringen muss man ein bisschen mehr als nur eine Endlosschleiche einbauen.

Ich werde heute mal versuchen ob ich Delphi in den Abgrund reiten kann.

grz zer00

Ist bei VB nicht so (also bei VB5, bei C ist natürlich was anders).
Mann muss den Debugger via CTRL+Break abwürge und mann wird nicht vom Debugger informiert ob ich will oder nicht, anyway sind ja schon recht vom Thema abgekommen