lupo45

Hey Dr. Melzer, den Call bei M$ werde ich vielleicht doch noch aufmachen, ein Aspekt ist halt: dat kost Geld! :mad: ein anderer: mich nervts! Also, die STOP-Meldung ist 0x00000050 Page fault in non paged area und ich hab sicherheitshalber mal'n Kernelspeicherabbild machen lassen Und die Sache sieht so aus: ich habe das betreffende User-Profil neu anlegen lassen, dann die User-Daten reinkopiert, Visio gestartet und: Bluescreen taucht immer noch auf! Ich also die User-Daten ins Backup-Profil zurückgeschoben, Profil nochmal neu angelegt und mit dem jungfräulichen Profil gestartet: schon wieder Bluescreen!!! :mad: :mad: Aber: mit anderen angemeldeten Usern funzt alles (und der betreffende der das Problem hat ist bereits lokaler Admin)! Was hat sich da wohl zerstrubbelt? Jetzt sind allerdings noch 2 Dinge zu beachten: 1. Im Nachhinein (ich hatte nur superwenig Zeit) ist mir durch den Kopf gegangen, dass bei einem Versuch Visio erst später, beim Datei öffnen die Kiste abgeschossen hat. Ein Unterschied zu sonst war: IntelliSync war noch nicht gestartet bzw. noch im Start-Vorgang, das war erst fertig nachdem Visio oben war. Werde das mal aus dem Autostart rausnehmen und schauen wie's komplett ohne läuft. 2. Der User bekommt bald (nächste 4-6Wochen) eh ein neues Notebook, da ist die Frage welcher Aufwand sich überhaupt noch lohnt (wie gesagt sind auf der Maschine eh soviele Apps installiert wie ich es selten gesehen habe, das alles neu zu machen...aua!). Habe für die Übergangsphase überlegt, ich richte ihm einfach einen zusätzlichen User ein und starte das Programm mit Ausführen-Als mit dem neuen User. Der bekommt dann Rechte auf die Eigenen Dateien von dem bestehenden und dann kann er erstmal arbeiten...und dann kann ich den Call bei M$ sparen. Den Crashdump kann ich dann immer noch zum Üben selbst analysieren, wenn ich M$-DebugFest endlich mal durchgearbeitet habe... :D

Versuch mal mit einem anderen User anzumelden und mit dem Word zu starten und die Datei zu öffnen. Wenn das funktioniert ist das Userprofil kaputt und müsste neu erstellt werden. Hatte in letzter Zeit sehr viele solche Probleme, die immer auf kaputte Profile zurückzuführen waren, daß also mit anderem angemeldetem User das Problem nicht nachvollziehbar war...

Fall irgendwas bockt, guckst du hier in Registry: HKLM\System\MountedDevices und schmeisst den entsprechenden Eintrag raus.

Wie wär's denn das Internet-Gateway entsprechend zu konfigurieren, daß Pakete ins Internet nur vom Proxy-Server (und ganz gezielten Systemen) zugelassen sind? Bei uns ist das so, wenn man keinen Proxy eingetragen hat dann gibt's nix mit Internet-Zugriff => Pech gehabt! Proxy-Zwang sozusagen... :D Ansonsten ist schon richtig: lokale Admins sind was anderes als Domain-Admins, denen kann man schon einiges verbieten, trotz Admin-Rechten!

Schonmal die Regions- und Sprachoptionen in der Systemsteuerung ausprobiert?

So sieht die Sache übrigens bei DOS 6.2 aus: http://dba-hq.de/echo.kein.fehler.JPG lefg: Schön, wenn du das noch nie gebraucht hast. Ich brauch's jetzt auch nicht mehr, da ich die Sache gezwungenermassen anders gelöst habe. Ich hatte halt ne Tonne kaskadierter Batches und hätte das gut zum Debuggen brauchen können...

Mein Gott, jetzt versteif dich doch nicht so auf Dinge die nicht ganz passen...ich mein, bevor ich was poste lese ich auch erstmal den ganzen Thread durch, wenn der Eröffnungspost nicht der Hit war, OK. Aber ich denke es sind andere Lösungsansätze beschrieben worden denen du nachgehen solltest, anstatt jetzt da rumzubohren. Würd mich freuen irgendwann zu lesen, wie du die Sache am Ende hinbekommen hast!

Wo ist das Problem, genau dies über eine VM zu regeln? Das Host-OS und die VM-Soft sorgen dafür, dass dein COM-Port wie auch immer zur Verfügung steht und in der VM starteste halt deine DOS-Boot-CD => fertich! :rolleyes: So wie ich das sehe ist das die einzige, robusteste und zukunftsorientierteste Lösung die du haben kanst, ohne dass an der Software an sich geschraubt wird... (OK, ich würd die Boot-CD dann noch so anpassen, dass da noch das DOS-Idle-Tool per autoexec.bat gestartet wird, damit die VM den Host nicht mit unnötiger CPU-Last lahmt bzw. den Akku plättet... :D )

Fritzcard ist ISDN, da is nix mit COM-Port. Der Vergleich hinkt ganz gewaltig... Wenn deine Anwendung in einer DOS-VM (die eingebaute vom W2k/XP) nicht läuft besteht immer noch die Möglichkeit über den Umweg einer echten VM, da du hier den W2K/XP-Com-Port, der vom PCMCIA-Treiber (falls der überhaupt notwendig ist) oder eben vom System selbst zu Verfügung gestellt wird, über eine virtuelle Maschine per VMware oder VirtualPC zu binden und somit zu benutzen. Wo ist da bitte das Problem? Wenn das hier genannte nicht schlagkräftig ist weiss ich es auch nicht mehr...sei doch froh daß du überhaupt Lösungsansätze für so altes Zeugs bekommst... :p

Was ist eine echte/physikalische Partition?

Ich denke man sollte davon ausgehen, daß solche Standard-Schnittstellen egal über welche Hardware entsprechend als COM-Ports eingebunden werden. Einen Treiber für Windows um das ggf. vom COM-Port zur PCMCIA-Hardware anzusprechen sollte dann mit der Hardware zur Verfügung stehen, je nachdem wie die Architektur im Detail aussieht, da man ja sonst keine Möglichkeit hat, so ein Teil zu benutzen. Und sobald das einmal als COM zur Verfügung steht sollte auch deine Antik-Software damit arbeiten können. Ansonsten, falls das wegen Probleme mit direkten Hardware-Zugriffen nicht will gibt's immer noch die Möglichkeit 'ne virtuelle DOS-Maschine mit VMware/Virtual-PC aufzusetzen, den COM-Port daran zu binden und die Software in der VM laufen zu lassen...ist zwar auch nicht ganz billig aber zumindest läuft's dann...

Wie wär's denn, das System mal als Standard-PC statt ACPI-PC aufzusetzen? Dazu muß man ACPI im BIOS deaktivieren und Windows neu installieren (da andere HAL)

Ansonsten kannst du auch mal auf http://www.sysinternals.com das Tool AutoRuns runterladen und auf dem System ausführen, da sieht man dann ob sich irgendwelche Hijacker-Tools oder so'n Dreck in die Autostarts/Run-Keys/etc. eingetragen haben. Oder alternativ halt mal AdAware oder Spybot Seek&Destroy ausprobieren...??

Gibt's vielleicht PCMCIA-Schnittstellen-Karten mit COM-Anschlüssen? Mach dich doch bzgl. sowas mal bei größeren Anbietern schlau...

Moin Velius, schätze das ist Definitionssache, ich finde schon, dass man so einige Bugs als Kuriositäten bezeichnen könnte. Beispiel gefällig? Hier: Notebook Compaq Armada E500, OS Windows XP. Habe extra so wenig wie möglich Anwendungen installiert und auch auf einige Compaq-"Tools" verzichtet, ausserdem überflüssige Programme aus den Autostarts/Run-Keys entfernt. Nun folgendes Verhalten bei eingeschalteter Option "Taskleiste automatisch ausblenden": sporadisch kommt es vor, daß die Taskleiste, obwohl in einer Anwendung gearbeitet wird, einfach nicht ausgeblendet wird. Man kann sich durch alle offenen Apps durchklicken, keine erwartet eine Eingabe (durch sowas wird das idR verursacht). Auch wenn ich alle Apps schliesse und auch die aus dem Task-Tray bringt das keine Änderung, die überlagert mir einfach den unteren Anzeigebereich. :mad: Das einzige was hilft (auch ohne alles zu zu machen) ist , die Taskleisten-Eigenschaften aufzurufen, diese Option zu deaktivieren, Übernehmen und dann wieder aktivieren: siehe da die Taskleiste verdünnisiert sich wieder. Aber warum denn nicht gleich so? Oder die Effekte mit Userprofiles, die ich hier beschreibe: http://www.mcseboard.de/showthread.php?t=59739 :mad: Wenn man erstmal nicht weiß woran solche nervigen Angelegenheiten nun genau liegen find ich's nicht abwegig von Kuriositäten zu sprechen, oder? BTW: hier beim Post schreiben auch eine meiner Ansicht nach Kuriosität: sobald ich einen Smiley über die Buttons rechts einfüge scrollt das Eingabefenster einfach nach ganz oben, obwohl der Cursor nach wie vor an der richtigen Stelle, nämlich hier unten, steht... Vielleicht liegt's am Firefox, aber so lange ich das nicht genau weiß finde ich das kurios!

Hab's nicht so verstanden, dass es schlecht gemacht wird. OK, es ist schon schlechter als psexec, weil's einige Features nicht bietet. Ein paar Kleinigkeiten bekommt man aber mit manuellem Strickwerk problemlos hin. Bei RCMD handelt es sich um ein Windows Resource Kit Tool, guckst du hier unter "Remote Command Service": http://www.petri.co.il/download_free_reskit_tools.htm Da Auslegungssachen für meine Begriffe schon genug Problempotential beinhalten bin ich jedenfalls gerade dabei von psexec nach rcmd bei einer sehr interessanten Scripting-Geschichte wegzumigrieren und werde psexec nur noch akut an der Konsole einsetzen. Ist nur grad so'n aktuelles Projekt bei mir... :)

Kann ich am Montag rausfinden. Da Autostart nach Bluescreen aktiviert ist konnte der User das nicht erkennen... Kann nicht zufällig einer hier Windows Kernel Debugging bzw. Crash-Dump-Analsysis?? Hab kein Bock bei M$'nen Call aufzumachen... :D (BTW: Schulungen zu dem Thema gibts angeblich von Sysinternals und kosten ca. 15.000€ pro Mann für 5 Tage, kann das einer bestätigen?)

Hey Kohn, dann lies mal bitte weiter: Also, wenn ich das einfach so an der Konsole eingebe ist alles bestens, aber sobald das z.B. im Task-Scheduler eingetragen oder in Batches verwendet wird...naja, mit RCMD ist man auf alle Fälle auf der sicheren Seite!

Hallo zusammen! Ich habe hier ein echt übles Problem mit einer Maschine und einem bestimmten Userprofil, hoffe da kann mir einer einen Tip geben: User A meldet sich als lokaler Admin an und will Visio 2003 std. starten. Während dem Start rebootet die Maschine wg. Absturz mit Bluescreen. Auch eine Neuinstallation der Anwendung brachte keine Änderung bzgl. diesem Effekt. Melde ich mich mit einem Benutzer B an, der auch lokale Admin-Rechte hat, aber der vorher noch kein Userprofil hatte, dann startet die Anwendung ganz normal. => Wie kann denn das bitte sein?!? Ich mein, in letzter Zeit häufen sich hier schon Probleme, die auf defekte Profile zurückzuführen sind, also die nach einer Profil-Neuanlage nicht mehr auftreten. Und das mit allen möglichen Anwendungen: Internet Explorer, Excel, Word, Acrobat Reader, Visio, Probleme mit Dateityp-Verknüpfugseinstellungen Aber das dabei das System komplett mit'nem Bluescreen abraucht hatte ich bisher noch nie und finde ich auch etwas sehr extrem für mein Empfinden. Vor allem in diesem konkreten Fall bin ich nicht so motiviert, das Profil neu anzulegen, da auf dieser Maschine derart viele Anwendungen installiert sind, daß da mit Sicherheit 3 Stunden für draufgehen werden, die Programme, die userspezifische Informationen installiert haben (z.B. IntelliSync), neu zu installieren. Mich würde mal interessieren, an welchen Schrauben man (vielleicht in der Registry) drehen muss, um solche Probleme zu beheben. Und noch ein Schmankerl zum Abschluss, den mir bisher auch noch keiner erklären konnte: Ich habe bei ca. 15 Maschinen 20 Leute am arbeiten, und zwar mit einem Roaming-Profile. Das Profil liegt auf einer Server-Share und alle bekommen genau dieses eine Profil (für jeden ist in den Domain-Account-Eigenschaften das gleiche Profil definiert). Ausserdem ist das Profil auf Mandatory konfiguriert, d.h. es wird NICHTS daran geändert. Bisher lief alles bestens und problemlos. Bis eine Ausnahme auftrat, dass ein spezieller User an einer speziellen Maschine ein Problem hatte: permanent hatte sich die Dateityp-Verknüpfung für PDF-Dateien zerstrubbelt und man musste immer wieder nach jeder Anmeldung für PDFs als Anwendung den Acrobat Reader einstellen. Komisch, wo doch alle anderen das Problem nicht hatten (auch an diesem System nicht), der User das an anderen Maschinen auch nicht hatte und ausserdem sowieso jeder das gleiche Mandatory-Profile zieht?! Jetzt das beste: Das Problem war beseitigt nachdem ich das lokal gecachte Profil gelöscht hatte und der User es durch Neuanmeldung komplett neu von der Server-Share gezogen hatte!! Interessant, oder?

BTW: mit RCMD funktioniert das auch. Vorraussetzung: man konfiguriert den RCMDSVC auf der Remote-Maschine vorher (natürlich im gestoppten Zustand) um mit: sc \\<remote-pc> config rcmdsvc type= own type= interact Kostet im Vergleich zu psexec halt nix... ;-) Nur ein Pferdefuss: der RCMD wartet auf Taskabschluss der Remote-Anwendung, das könnte etwas nervig sein. Hatte mal mit diversen START-Spielarten rumexperimentiert, aber wie man's auch dreht: RCMD "bemerkt" offenbar alle geöffneten Child-Prozesse unter RCMDSVC. Falls da noch jemand'ne Idee zu hat wär ich dankbar! (würde der Funktionalität nach dem Parameter -d bei psexec entsprechen)

Hey Murphy, "gar keine Befehle"...ich würd sagen das ist das gleiche Problem. Wenn du SET oder DATE oder TIME eingibst wird das funktionieren, weil das ein interner Befehl ist. Ping ist genau wie NET oder IPCONFIG ein externer Befehl im System-Verzeichnis. Workaround ist wie gesagt einfach in der Path-Variable über Eigenschaften-Arbeitsplatz/Erweitert/Umgebungsvariblen den Klartext "c:\windows" statt %systemroot% einzutragen. Ist halt nicht sauber aber zumindest kann man erstmal wieder arbeiten. Die Ursache würd mich aber dennoch mal interessieren!

Hallo zusammen, ich habe hier einen ziemlich interessanten Effekt auf einer XP-Workstation. An dieser maschine funktionierte zuerst das Anmeldeskript nicht bzgl. der Netzlaufwerke. Hab dann mal die Konsole gestartet um ein paar Sachen nachzuschauen, aber ich konnte keine Befehle (net, ipconfig, regedit) ausführen. Als ich mir dann mit SET mal die Umgebungsvariablen angeschaut habe ist mir aufgefallen, dass bei allen Einträgen, die mit SystemRoot eingetragen waren, die Variable im Klartext angezeigt wird! Schaut man sich die Variablen über die System-Eigenschaften an wird's komischerweise korrekt angezeigt, nur per SET an der Konsole nicht. Nachdem ich die Variable durch c:\windows ersetzt hatte funktionierten die Systembefehle wieder, auch das Anmeldeskript lief korrekt durch. Aber sauber ist das ja nicht wirklich... Was kann denn das bitte sein?

@overlord: mit loopback-Adapter meinte ich den von M$, den Netzwerk-Loopback-Adapter. Hatte als Alternative zum Subst-Mounting in Betracht gezogen, das Verzeichnis von der C-Platte freizugeben und auf Lw.D: über Netzlaufwerkverbindung einzubinden...nur das Ergebnis von dem Test mit der Testmaschine macht mich doch stuzig: hat vielleicht nur die betreffende Workstation ein OS-Problem? Würde keinen Sinn machen, warum sich das OS mal so mal so verhält...außer XP und 2000 verhalten sich unterschiedlich, was ich mir aber auch nicht vorstellen kann, weil dann in dem Fall 2000 korrekt funktioniert und XP nicht. Was soll man nun davon halten?!

hmmm, genau den Gedanken hatte ich auch vorhin, mit dem Loopback-Adapter würde das vielleicht funktionieren. ABER: ich habe gerade mal versucht, das Problem auf'ner Testkiste nachzuvollziehen. Habe eine virtuelle W2k-Maschine im VMware und USB aktiviert. Hier wird der Stick komischerweise direkt auf Lw. F: eingebunden und Lw. D: (per Subst eingebunden) lässt er in Ruhe...wie kann denn das jetzt sein?!? :mad:

Was zuerst kommt ist ganz klar: der Subst-Befehl. Also, die Kiste wird hochgefahren, User meldet sich an, hat Lw. D: per Subst bekommen, ist also per Explorer browse-bar. Dann steckt mann irgendwann den Memory-Stick in den USB-Port und dann zerstrubbelt sich die Zuordnung, weil das OS den bereits per Subst gemounteten Lw.-Buchstaben für den Wechseldatenträger verwenden will... :mad: :mad: :mad: Und wie das bei Windows halt so ist muss man für jeden Memorystick, den man das erste mal an der Maschine verwendet, erneut das Gerät von Lw. D: weg auf ein anderes (hier Lw. F: ) per Datenträgerverwaltung umkonfigurieren... :mad: :mad: :mad: