For a many month I am unable to install ReactOS with DBG=1 and KDBG=1 enabled.
On the same hardware, version with DBG=0 and KDBG=0 installs and runs fine.
DBG=1, KDBG=1 enabled ReactOS booted by freeldr asks for COMUTERNAME, Name, password, time zone etc. etc. and asks for reboot.
Then it bugchecks with :
bt Frames: vmwinst.exe: vmwinst.c: 75 (DetectVMware)
bugcheck KeBugCheck at dbg/kdb.c: 1495 Bug detected (code deaddead param 0 0 0 0) Page fault at high IRQL was 2 KeBugCheckWithTf at ke/catch.c:165 Bug detected (code 1e param 0 0 0 0) KMODE_EXCEPTION_NOT_HANDLED Page fault Exception: 14(0)
Processo: 0 CS:EIP 8:c00b8cb7 <ntoskrnl.exe: rtl/message.c:108 (RtlFindMessage)> cr2 e07a4604 cr3 1d84a000 Proc: c0eb1c90 Pid:7 <vmwinst> Thrd: c0ebd08 Tid: 2c DS 10 ES 10 FS 30 GS 10
kernel stack base df255000
KeBugCheckWithTf KeBugCheckEx KeBugCheck DbgBugCheckCommand KdbDoCommand KdbMainLoop KdbInternalEnter KdbEnterDebuggerException KiDispatchException ke/i386/usertrap.c: 139 KiUserTrapHandler ke/i386/exp.c: 613 KiTrapHandler /tmp/ccphDdwg.s: 146 KeUserModeCallback
vmwinst.c: 75 DetectVMware vmwinst.c:1016 WinMain 1047 WinMain kernel32.dll: BaseProcessStart <DEADBEEF>
If someone is interested in more debugging informations, I can send processor registers and map files.
Regards,
David
The only way to detect if it is running under vmware is to try a instruktion, which trows an exception if it isn't running under vmware. 2 solutions: - try to continue with the kernel debugger - kill/rename the vmwinst.exe
For a many month I am unable to install ReactOS with DBG=1 and KDBG=1 enabled.
On the same hardware, version with DBG=0 and KDBG=0 installs and runs fine.
DBG=1, KDBG=1 enabled ReactOS booted by freeldr asks for COMUTERNAME, Name, password, time zone etc. etc. and asks for reboot.
Then it bugchecks with :
bt Frames: vmwinst.exe: vmwinst.c: 75 (DetectVMware)
bugcheck KeBugCheck at dbg/kdb.c: 1495 Bug detected (code deaddead param 0 0 0 0) Page fault at high IRQL was 2 KeBugCheckWithTf at ke/catch.c:165 Bug detected (code 1e param 0 0 0 0) KMODE_EXCEPTION_NOT_HANDLED Page fault Exception: 14(0)
Processo: 0 CS:EIP 8:c00b8cb7 <ntoskrnl.exe: rtl/message.c:108 (RtlFindMessage)> cr2 e07a4604 cr3 1d84a000 Proc: c0eb1c90 Pid:7 <vmwinst> Thrd: c0ebd08 Tid: 2c DS 10 ES 10 FS 30 GS 10
kernel stack base df255000
KeBugCheckWithTf KeBugCheckEx KeBugCheck DbgBugCheckCommand KdbDoCommand KdbMainLoop KdbInternalEnter KdbEnterDebuggerException KiDispatchException ke/i386/usertrap.c: 139 KiUserTrapHandler ke/i386/exp.c: 613 KiTrapHandler /tmp/ccphDdwg.s: 146 KeUserModeCallback
vmwinst.c: 75 DetectVMware vmwinst.c:1016 WinMain 1047 WinMain kernel32.dll: BaseProcessStart <DEADBEEF>
If someone is interested in more debugging informations, I can send processor registers and map files.
Regards,
David
-- David Kredba <kredba at ibot.cas.cz> GPG: ID 1024D/5B6B02DE Fingerprint: F0B3312596BEDCF91DFB 0699E06AACD75B6B02DE _______________________________________________ Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
On Wed, 17 Nov 2004 16:32:30 +0100 (CET) michael@fritscher.net wrote:
The only way to detect if it is running under vmware is to try a instruktion, which trows an exception if it isn't running under vmware. 2 solutions:
- try to continue with the kernel debugger
- kill/rename the vmwinst.exe
For a many month I am unable to install ReactOS with DBG=1 and KDBG=1 enabled.
On the same hardware, version with DBG=0 and KDBG=0 installs and runs fine.
DBG=1, KDBG=1 enabled ReactOS booted by freeldr asks for COMUTERNAME, Name, password, time zone etc. etc. and asks for reboot.
If you hit cancel, it will skip vmware detection IIRC. That should be made more clear somehow.
art yerkes wrote:
If you hit cancel, it will skip vmware detection IIRC. That should be
made more clear somehow.
The setup will only be displayed if it's actually running inside of vmware. If you try to run vmwinst.exe on other platforms it will terminate immediately, nothing should happen. The detection works through a (undocumented, but well-known) i/o operation in umode on a specific port - which will result in a umode exception on regular systems. So whenever the operation succeeds it knows there's vmware. Due to the lack of seh back then when I wrote the utility, i had to setup a exception handler that just terminates the process. Again, it should not raise any kmode exception, it only performs a privilleged instruction which raises an umode exception on regular systems.
Best Regards, Thomas
It raises kmode exception for me only with KDBG=1 && DBG=1 set.
It is on real hw, no VMware there.
Thanks, David
Thomas Weidenmueller wrote:
Again, it should not raise any kmode exception, it only performs a privilleged instruction which raises an umode exception on regular systems.
Best Regards, Thomas _______________________________________________
Again, it should not raise any kmode exception, it only performs a privilleged instruction which raises an umode exception on regular systems.
Best Regards, Thomas
Our kdbg handles *all* exceptions last time I looked. dwelch told me not to turn that off, because he wanted it that way.
So it is clear.
Workaround for me should be to delete or rename vmwinst.exe before the initial boot.
I`ll try.
David
art yerkes wrote:
Again, it should not raise any kmode exception, it only performs a privilleged instruction which raises an umode exception on regular systems.
Best Regards, Thomas
Our kdbg handles *all* exceptions last time I looked. dwelch told me not to turn that off, because he wanted it that way.
art yerkes wrote:
Our kdbg handles *all* exceptions last time I looked. dwelch told me not to turn that off, because he wanted it that way.
Hm, that's not really good news - it's a handled exception, there are tons of applications that raise exceptions in certain situations, it kinda sucks when kdbg is entered every time for those things. I don't really see a point for leaving this enabled, it just causes a lot of pain (that's propably why i prefer not to use KDGB because it just bugs me)...
Thomas
art yerkes wrote:
Our kdbg handles *all* exceptions last time I looked. dwelch told me not to turn that off, because he wanted it that way.
I forgot to mention that there's no other reliable way to test whether the system is running in vmware or not. It's not an unhandled exception so I don't think it's justified to enter kdgb there.
Thomas