What is difference in installation procedure w/wo DGG, KDBG set ?

[David Kredba]

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

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(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev
>

[art yerkes]

On Wed, 17 Nov 2004 16:32:30 +0100 (CET)
michael(a)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.

-- 
Here's a simple experiment. Stand on a train track between two locomotives
which are pushing on you with equal force in opposite directions. You will
exhibit no net motion. None the less, you may soon begin to notice that
something important is happening.
-- Robert Stirniman

[Thomas Weidenmueller]

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

[David Kredba]

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
>  _______________________________________________ 
-- 
David Kredba  <kredba at ibot.cas.cz>
GPG: ID 1024D/5B6B02DE
Fingerprint: F0B3312596BEDCF91DFB 0699E06AACD75B6B02DE

[art yerkes]

>   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.
-- 
Here's a simple experiment. Stand on a train track between two locomotives
which are pushing on you with equal force in opposite directions. You will
exhibit no net motion. None the less, you may soon begin to notice that
something important is happening.
-- Robert Stirniman

[David Kredba]

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. 

-- 
David Kredba  <kredba at ibot.cas.cz>
GPG: ID 1024D/5B6B02DE
Fingerprint: F0B3312596BEDCF91DFB 0699E06AACD75B6B02DE

[Thomas Weidenmueller]

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

[Thomas Weidenmueller]

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