Ros-dev May 2005

ros-dev@reactos.org

68 participants
173 discussions

VMS environment subsystem for ReactOS
by ea 01 May '05

01 May '05

Hi all, even if it is only an empty framework, I want to make you know yesterday I committed the source code of an optional environment subsystem for emulating VMS. Note it is far from complete and it has no ReactOS specific code (which will be *required* to run), but it may be used as a template. Recently ReactOS, which is a free and open source reimplementation of the core NT kernel+executive and driver model with multiple user mode OS personalities, was added the effective ability to load other optional subsystem, like POSIX (researched) or, say, VMS. If somebody on the list is interested in this project, please, feel free to contact me privately. Emanuele Aliberti ea(a)reactos.com

1 0

Multiple problems with HEAD
by Ge van Geldorp 01 May '05

01 May '05

1st problem: when booting rev 14873 (DBG := 1, KDBG := 0) it crashes with: DriverBase for \SystemRoot\system32\drivers\fs_rec.sys: 9cf7c000 (io/file.c:898) Status :0 (io/file.c:898) Status :0 (io/file.c:898) Status :0 DriverBase for \SystemRoot\system32\drivers\beep.sys: 9cf8b000 (io/file.c:898) Status :0 Assertion NewRefCount >= 0 failed at ob/object.c:1150 KeBugCheckWithTf at ke/catch.c:217 A problem has been detected and ReactOS has been shut down to prevent damage to your computer. The problem seems to be caused by the following file: ntoskrnl.exe KMODE_EXCEPTION_NOT_HANDLED Technical information: *** STOP: 0x0000001E (0x80000003,0x800057a4,0x8005d08b,0x8071c9ec) *** ntoskrnl.exe - Address 0x800057a4 base at 0x80000000, DateStamp 0x0 Breakpoint Exception: 3(0) Processor: 0 CS:EIP 8:800057a4 <ntoskrnl.exe: 57a4> cr2 8ccfc000 cr3 27000 Proc: 8053fcf8 Pid: 4 <System> Thrd: 805407f0 Tid: 0 DS 10 ES 10 FS 30 GS 10 EAX: 00000036 EBX: 8004515d ECX: 00000000 EDX: 000003f8 EBP: 800e47a4 ESI: 800e4a84 ESP: 800e4730 EDI: 800e49f4 EFLAGS: 00200286 kESP 800e4730 kernel stack base 800e3000 Frames: <ntoskrnl.exe: 72a9f> <ntoskrnl.exe: 45f2a> <ntoskrnl.exe: 456e1> <vfatfs.sys: 2d00> <vfatfs.sys: d1de> <vfatfs.sys: d3ee> <ntoskrnl.exe: 45158> <ntoskrnl.exe: 40487> <ntoskrnl.exe: 414dd> <ntoskrnl.exe: 3602> <7D83F045> <ntoskrnl.exe: 3e6c0> <ntoskrnl.exe: 3602> <EC83FC45> <ntoskrnl.exe: 3de8e> <800A48CE> <800A21D4> <ntoskrnl.exe: 10004> <800A07AA> <ntoskrnl.exe: 104b> 2nd problem: the crash info is only written to the debug log and not shown as a BSOD. 3rd problem: the stack trace only shows addresses, not source file/line as it should for a DBG build 4th problem: booting with /DEBUGPORT=GDB results in a kernel stack fault very early in the boot process. Gé van Geldorp.

3 6

Re: [ros-svn] [ion] 14884: Add hack for ROS's weird behavior. Will investigate but this lets you boot for now
by Alex Ionescu 01 May '05

01 May '05

ion(a)svn.reactos.com wrote: >Add hack for ROS's weird behavior. Will investigate but this lets you boot for now > > >Updated files: >trunk/reactos/ntoskrnl/io/irp.c > > > The problem is that a bunch of places in the code set the FileObject Event as the UserEvent. This is incredibly wrong, because both are used to signal completely different things and shouldn't be used like that. I've changed them to local stack KEVENTS, but this still fails, because you cannot dereference them. The check for !IRP_SYNCHRONOUS_API is meant to ensure against this (Syncronous IRPs have KEVENTS, Async ones have Executive Events, in short terms.) I've researched some more and this is because of a bigger problem. The routines doing the hack all assumed that the File Object is Synchronous and build a Sync FSD (with IRP_SYNCH_API set), and then set a KEVENT UserEvent. They should actually check if the File Object is Sync or Async, and in case of Async they should use the Local Stack KEVENT (which won't be dereferenced because of the check in IoCompleteRequest APC (2nd stage)), while in case of async they shouldn't use any event at all and wait on the file object instead of waiting on the local event. Also, in case of a sync operation, we must eventually include some sort of locking/unlocking of the file object for serialized access which is required. I will spend some time tomorrow working with these issues so the hack can be removed and proper kernel functionality to be restored, but I wanted to share the background information. Best regards, Alex Ionescu

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev May 2005