Ros-dev

ros-dev@reactos.org

5790 discussions

Build 20583 bluescreens

by Alex Buell

Just got ReactOS to build and boot, but bluescreens during the GUI based setup. It looks like there's something wrong with the code that services the mouse. (./ntoskrnl/ke/main.c:295) --------------------------------------------------------------- (./ntoskrnl/ke/main.c:296) ReactOS 0.3-SVN (Build 20060105-r20584) Used memory 131072Kb (./ntoskrnl/mm/mminit.c:386) Kernel Stack Limits. InitTop = 0x800ba000, Init = 0x800b7000 (./ntoskrnl/mm/mm.c:283) No current process (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\System32\drivers\serial.sys (Status 0xc0000001) (./ntoskrnl/io/pnpmgr.c:2168) Initialization of service serial failed (Status c0000001) (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\System32\drivers\serial.sys (Status 0xc0000001) (./ntoskrnl/io/pnpmgr.c:2168) Initialization of service serial failed (Status c0000001) (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\System32\drivers\serial.sys (Status 0xc0000001) (./ntoskrnl/io/pnpmgr.c:2168) Initialization of service serial failed (Status c0000001) (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\System32\drivers\serial.sys (Status 0xc0000001) (./ntoskrnl/io/pnpmgr.c:2168) Initialization of service serial failed (Status c0000001) (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\System32\drivers\pcnet.sys (Status 0xc0000001) (./ntoskrnl/io/pnpmgr.c:2168) Initialization of service PCNet failed (Status c0000001) (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\system32\drivers\vmx_svga.sys (Status 0xc0000001) (./ntoskrnl/io/pnpmgr.c:2168) Initialization of service vmx_svga failed (Status c0000001) (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\System32\drivers\pciide.sys (Status 0xc0000001) (./ntoskrnl/io/pnpmgr.c:2168) Initialization of service pciide failed (Status c0000001) (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\System32\drivers\pcnet.sys (Status 0xc0000001) (./ntoskrnl/io/pnpmgr.c:2168) Initialization of service PCNet failed (Status c0000001) (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\system32\drivers\vmx_svga.sys (Status 0xc0000001) (./ntoskrnl/io/pnpmgr.c:2168) Initialization of service vmx_svga failed (Status c0000001) (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\System32\drivers\pciide.sys (Status 0xc0000001) (./ntoskrnl/io/pnpmgr.c:2168) Initialization of service pciide failed (Status c0000001) (./ntoskrnl/io/pnpreport.c:86) IoReportResourceForDetection partly implemented (./ntoskrnl/io/pnpmgr.c:545) IoOpenDeviceRegistryKey(): Base key doesn't exist, exiting... (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\System32\drivers\pciide.sys (Status 0xc0000034) (./ntoskrnl/io/pnpmgr.c:2168) Initialization of service pciide failed (Status c0000034) (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\system32\drivers\sndblst.sys (Status 0xc0000034) (./ntoskrnl/ldr/loader.c:267) Could not open module file: \SystemRoot\system32\drivers\mpu401.sys (Status 0xc0000034) (./ntoskrnl/io/disk.c:630) RDiskCount 2 (./subsys/win32k/ntuser/winsta.c:108) IntWinStaObjectOpen (./subsys/win32k/ntuser/winsta.c:118) Create winsta atomtable (./subsys/win32k/ntuser/desktop.c:812) Trying to open desktop (\Windows \WindowStations\WinSta0\Default) (./subsys/win32k/ntuser/desktop.c:646) IntShellHookNotify: No desktop! (./subsys/win32k/ntuser/desktop.c:812) Trying to open desktop (\Windows\WindowStations\WinSta0\Winlogon) (./subsys/win32k/ntuser/desktop.c:646) IntShellHookNotify: No desktop! (./subsys/win32k/ntuser/desktop.c:812) Trying to open desktop (\Windows \WindowStations\WinSta0\Screen-Saver) (./subsys/win32k/ntuser/desktop.c:646) IntShellHookNotify: No desktop! WL-Status: ReactOS is starting up... WARNING: WSHGetSockaddrType at drivers/net/wshtcpip/wshtcpip.c:103 is UNIMPLEMENTED! (services/dhcp/util.c:72) ERROR: util.c read_client_conf not implemented! 81178950: 00 00 00 00 c8 e4 64 00 01 00 00 00 00 00 00 00 ......d......... 81178960: 34 e5 64 00 34 20 76 00 ac 10 75 02 03 00 00 00 4.d.4 v...u..... 81178970: ac 18 65 00 c8 e4 64 00 00 00 00 00 b8 43 76 00 ..e...d......Cv. 81178980: 00 00 00 00 .... FIXME: CopyImage doesn't support IMAGE_ICON correctly! (lib/ntdll/ldr/utils.c:1190) LdrGetExportByName(): failed to find mxdMessage (lib/ntdll/ldr/utils.c:2015) Failed to create or open dll section of 'msacm.drv' (Status c0000135) (lib/ntdll/ldr/utils.c:2015) Failed to create or open dll section of 'midimap.drv' (Status c0000135) (SAMLIB:lib/samlib/samlib.c:399) User already exists! (lib/setupapi/devinst.c:3167) Flags 0x800000 ignored (lib/setupapi/devinst.c:3167) Flags 0x800000 ignored (lib/setupapi/devinst.c:3167) Flags 0x800000 ignored (lib/setupapi/devinst.c:3167) Flags 0x800000 ignored (lib/setupapi/devinst.c:3167) Flags 0x800000 ignored (lib/setupapi/devinst.c:3167) Flags 0x800000 ignored (lib/setupapi/devinst.c:3167) Flags 0x800000 ignored (lib/setupapi/devinst.c:3167) Flags 0x800000 ignored (lib/setupapi/devinst.c:3167) Flags 0x800000 ignored (lib/setupapi/devinst.c:3167) Flags 0x800000 ignored (./lib/advapi32/service/scm.c:2036) dwBufSize: 0 (subsys/system/services/rpcserver.c:1759) ScmrStartServiceW() called (./ntoskrnl/mm/mm.c:275) Page fault at high IRQL was 2, address 156 KeBugCheckWithTf at ntoskrnl/ke/i386/exp.c:1242 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 Technical information: *** STOP: 0x0000001E (0xc0000005,0x800028dd,0x00000000,0x00000156) *** ntoskrnl.exe - Address 0x800028dd base at 0x80000000, DateStamp 0x0 Page Fault Exception: 14(0) Processor: 0 CS:EIP 8:800028dd <ntoskrnl.exe:28dd (./ntoskrnl/ke/wait.c:0 ())> cr2 156 cr3 26000 Proc: 80804c20 Pid: 4 <System> Thrd: 80d6c7d8 Tid: 80 DS 23 ES 23 FS 30 GS 0 EAX: 9e458c14 EBX: 00000102 ECX: 00000102 EDX: 00000004 EBP: 9e458b80 ESI: 00000000 ESP: 9e458b04 EDI: 80d6c7d8 EFLAGS: 00010206 kESP 9e458b04 kernel stack base 9e456000 Frames: <ntoskrnl.exe:34d5 (./ntoskrnl/ke/event.c:207 (KeSetEvent))> <ntoskrnl.exe:29109 (./ntoskrnl/io/irp.c:0 (IopCompleteRequest))> <ntoskrnl.exe:3164 (./ntoskrnl/ke/apc.c:0 (KiDeliverApc))> <80405EAE> <win32k.sys:3b3ed (./subsys/win32k/eng/mouse.c:588 (IntEngMovePointer))> <win32k.sys:5d299 (./subsys/win32k/ntuser/input.c:0 ())> <win32k.sys:5dc4b (./subsys/win32k/ntuser/input.c:148 (ProcessMouseInputData))> <win32k.sys:5de0f (./subsys/win32k/ntuser/input.c:227 (MouseThreadMain))> <ntoskrnl.exe:5aeab (./ntoskrnl/ps/thread.c:94 (PspSystemThreadStartup)) > <ntoskrnl.exe:62265 (ntoskrnl/ke/i386/ctxswitch.S:82 (KiThreadStartup))> -- http://www.munted.org.uk Anyone that thinks an imaginary deity is going to protect them against earthquakes and hurricanes needs psychiatric help.

19 years, 9 months

Build 20583 blows up with the following

by Alex Buell

obj-i386/ntoskrnl/ke/i386/kernel.o: In function `KeApplicationProcessorInitDispatcher': /home/alex/src/OpSys/reactos/ntoskrnl/ke/i386/kernel.c:147: undefined reference to `@KeAcquireDispatcherDatabaseLock@0' /home/alex/src/OpSys/reactos/ntoskrnl/ke/i386/kernel.c:149: undefined reference to `@KeReleaseDispatcherDatabaseLock@4' obj-i386/ntoskrnl/ke/i386/kernel.o: In function `KeInit2': /home/alex/src/OpSys/reactos/ntoskrnl/ke/i386/kernel.c:442: undefined reference to `@KeInitializeDispatcher@0' collect2: ld returned 1 exit status -- http://www.munted.org.uk Anyone that thinks an imaginary deity is going to protect them against earthquakes and hurricanes needs psychiatric help.

19 years, 9 months

RE: [ion] 20554: - Fix shamefully dangerously broken WorkThread/Queue/Item implementation:

by Ge van Geldorp

> From: ion(a)svn.reactos.org > > * Do not pollute the kernel with 10 real-time threads and 5 > high-priority threads in order to manage work items. Work > threads are very-low priority (< 7) and should never pre-empt > userthreads like they do now. 1 priority 7, 5 priority 5 and > 3 priority 4 threads are now properly created. I haven't looked at your code yet, but the comment worries me. Does it mean that if a usermode app is stuck in a "while (1) ;" loop stuff queued by IoAllocateWorkItem( ) never gets executed? If I misunderstood, nevermind, disregard this message. If this is true we're in big trouble. We're using work items in a lot of places to get from DPC level to PASSIVE level. For example, the networking stack queues a work item when data was received from the network card. I'd hate to see a stuck usermode app halt all network communications... GvG

19 years, 9 months

Re: [ros-diffs] [ion] 20579: - Change dispatcher lock release to be more like documented in Windows Internals II and to allow an easier move to Queued Spinlock.

by Hartmut Birr

ion(a)svn.reactos.org wrote: > - Change dispatcher lock release to be more like documented in Windows Internals II and to allow an easier move to Queued Spinlock. > Modified: trunk/reactos/ntoskrnl/include/internal/ke.h > Modified: trunk/reactos/ntoskrnl/ke/wait.c > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/ntoskrnl/include/internal/ke.h* > --- trunk/reactos/ntoskrnl/include/internal/ke.h 2006-01-05 15:29:08 UTC (rev 20578) > +++ trunk/reactos/ntoskrnl/include/internal/ke.h 2006-01-05 15:32:08 UTC (rev 20579) > @@ -51,6 +51,7 @@ > #ifndef CONFIG_SMP > #define KeInitializeDispatcher() > #define KeAcquireDispatcherDatabaseLock() KeRaiseIrqlToDpcLevel(); > > +#define KeReleaseDispatcherDatabaseLock(OldIrql) KiExitDispatcher(OldIrql); > > #define KeAcquireDispatcherDatabaseLockAtDpcLevel() > #define KeReleaseDispatcherDatabaseLockFromDpcLevel() > #else > @@ -60,6 +61,9 @@ > > KeAcquireSpinLockAtDpcLevel (&DispatcherDatabaseLock); > #define KeReleaseDispatcherDatabaseLockFromDpcLevel() \ > KeReleaseSpinLockFromDpcLevel(&DispatcherDatabaseLock); > > +#define KeReleaseDispatcherDatabaseLock(OldIrql) \ > + KeReleaseSpinLockFromDpcLevel(&DispatcherDatabaseLock); \ > + KiExitDispatcher(OldIrql); > > #endif > I don't like inverted logic. It is more readable like this: #ifdef CONFIG_SMP ... #else ... #endif - Hartmut

19 years, 9 months

tools/rbuild/backend/mingw/modulehandler.h

by Reuben Perelman

I was getting this error when trying to compile reactos: > reub2000@reub2000 ~/reactos $ make > [MKDIR] obj-i386/tools > [MKDIR] obj-i386/tools/rbuild > [MKDIR] obj-i386/tools/rbuild/backend > [MKDIR] obj-i386/tools/rbuild/backend/mingw > [CC] tools/rbuild/backend/mingw/mingw.cpp > tools/rbuild/backend/mingw/modulehandler.h:91: error: extra > qualification ‘MingwModuleHandler::’ on member > ‘GetCompilationUnitDependencies’ > tools/rbuild/backend/mingw/modulehandler.h:150: error: extra > qualification ‘MingwModuleHandler::’ on member > ‘GetPrecompiledHeaderFilename’ > make: *** [obj-i386/tools/rbuild/backend/mingw/mingw.o] Error 1 Looking at the file, I couldn't understand why MingwModuleHandler:: was being used within the class of the same name, so I removed it from before the definition of the functions. I'm guessing that it was copied from the function definition outside of the class in a .cpp file? Anyways, this seems to allow reactos to compile: > Index: tools/rbuild/backend/mingw/modulehandler.h > =================================================================== > --- tools/rbuild/backend/mingw/modulehandler.h (revision 20484) > +++ tools/rbuild/backend/mingw/modulehandler.h (working copy) > @@ -88,7 +88,7 @@ > std::string GetBasename ( const std::string& filename ) const; > FileLocation* GetActualSourceFilename ( const FileLocation* > fileLocation ) const; > std::string GetExtraDependencies ( const std::string& filename ) const; > - std::string MingwModuleHandler::GetCompilationUnitDependencies ( > const CompilationUnit& compilationUnit ) const; > + std::string GetCompilationUnitDependencies ( const CompilationUnit& > compilationUnit ) const; > std::string GetModuleArchiveFilename () const; > bool IsGeneratedFile ( const File& file ) const; > std::string GetImportLibraryDependency ( const Module& importedModule ); > @@ -147,7 +147,7 @@ > std::string GenerateGccIncludeParameters () const; > std::string GenerateGccParameters () const; > std::string GenerateNasmParameters () const; > - std::string MingwModuleHandler::GetPrecompiledHeaderFilename () const; > + std::string GetPrecompiledHeaderFilename () const; > void GenerateGccCommand ( const FileLocation* sourceFileLocation, > const std::string& extraDependencies, > const std::string& cc, Also, I saw a lot of 'std::'. Why not use 'using namespace std;'?

19 years, 9 months

Optimization Proposal

by Alex Ionescu

Hi, I have come to the conclusion that using -O2 is beneficial even for DBG = 1 builds, and that it should be set on by default on all builds. The typically given reason for not using optimizations on a "Debug" build is because these apparently make assembly code harder to read. I have realized otherwise, and as seen in the example that I will include below, I'm sure this will be mutually agreed on. I note the following advantages in using -O2 on a DBG = 1 build as well: - -O2 makes the compiler do additional checks. For example, gcc will NOT detect uninitialized variables unless -O2 is being used, even though they are a very important programming bug. Apart from finding more bugs, it also makes trunk compilable. Right now, I see at least two commits by Thomas or others being made every week in order to fix some code which used unitinialized variables (I myself have been guilty of this). This means that some of us, like Thomas, have to constantly fix other people's mistakes. - -O2 means less last-minute blockers. Because we release in -O2 but almost never build it like that, this creates a big problem for people like Andrew or Brandon, which handle the release process and do testing. Because the -O2 build gets less testing coverage, it is very possible for a critical bug to be in ROS for a month before anyone notices it at release time, in which case we will all have to scramble to find a fix for it. - -O2 will not undefine DBG or change anything else in the code. All the advatanges, extra error checking and assertions of the DBG =1 build would remain. - -O2 builds are much faster, greatly helping testing speed. - -O2 builds are much more likely to bring up race conditions and other important timing bugs we need to watch out for. - -O2 means easier debugging. This point is really important because until I realized how true it was, I didn't want to bring this up. Here is a pseudo(but real) disassembly of something I've seen in my dbg = 1 kernel binary while debugging: 0x40b845: push ebp mov ebp, esp sub esp, 4 mov [ebp-4], fs:18h mov eax, [ebp-4] leave retn 0x4bc8a5: push ebp mov ebp, esp sub esp, 4 call 0x40b845 mov ecx, [eax+1c] mov [ebp-4], eax mov eax, [ebp-4] leave retn 0x42b845: push ebp mov ebp, esp sub esp, 4 call 0x4bc8a5 mov ecx, [eax+124] mov [ebp-4], eax mov eax, [ebp-4] leave retn KeFooBar: push ebp mov ebp, esp sub esp, 4c call 0x42b845 mov [ebp-0xc], eax mov eax, [ebp-0xc] <..> leave retn This is how it looks with -O2 KeFooBar: push ebp mov ebp, esp sub esp, 4c mov eax, fs:124h <..> leave retn I hope we can all agree on which one of these is readable. The -O2 build clearly shows you that eax is fs:124h, which you oughta know is Pcrb->CurrentThread; even if you don't, you can easily check in a header. The non-o2 build calls 3 other functions, out of which 2 are merely calling other functions themselves (due to lack of symbols you have no way of knowing what these functions are doing), until we finally get to a function which does fs:18, which you then realize is the PCR, you then walk back and realize pcr->0x1c is PCRB, and Prcb->0x124 is current thread. Yes, this example could easily be destroyed by saying " use a #define with inline assembly" but I can bring many more; we can't start using inline assembly everywhere... msvc does an amazing job at optimizing these things, and even gcc isn't that bad, if only you let it. Code built without -o2 makes horrible usage of the stack, which makes you have to memory a lot more addresses then code which simple stores values in registers. Because humans are smart, the loops generated by -O2 are also much closer to what someone that understands assembly is used to (for example, the loop will use ecx, and not a stack variable that you need to memorize). I consider myself an expert on assembly coding, and I simply have great trouble reading non-O2 kernels, so how exactly does it help debugging? In the end, I am convinced that the only disadvantage of using -O2 by default is that it will slightly increase build times. I don't think this increase is more then, at most 1 minute or two for a complete build. If this issue is really critical to someone people, then perhaps only core system files should use -O2 (kernel32, ntdll, ntoskrnl, csr, win32k, drivers, etc). I know some of the developers on IRC are strongly for this, but I want to make sure I get a broader opinion. Best regards, Alex Ionescu

19 years, 9 months

RE: [ros-dev] Optimization Proposal

by Murphy, Ged (Bolton)

Ge van Geldorp wrote: > Yup, using Insight (the cygwin GUI for gdb), which connects > over a null > modem to the GDB stub in ntoskrnl. I'm using a > slightly-modified version, > since the official one insists that when doing a stack > backtrace the frame > pointer should increase for each stack frame (which is > correct generally but > breaks when you're backtracing from the kernelmode stack back into the > usermode stack). Also the official version has a problem with hardware > watchpoints. I use the Win32 port which comes as an add-on package with DevCpp. However I've recently switched my pen drive compiler from DevCpp to Code::Blocks I'm finding the Code::Blocks built in debugger (which also uses mingw gdb) to be excellent and have started using that in place of Insight, as it doesn't seem have any of the problems Insight has. In fact, I'm so impressed with Code::Blocks as a whole, I think it makes DevCpp obsolete and needs a backend writing for rbuild. It's certainly the best mingw enabled development tool for ROS I've come across. ;) Ged. ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

19 years, 9 months

Re: [ros-svn] [jimtabor] 20559: Clean up and fixed NtUserGetMenuItemRect. Needs more testing. I watch mplayerc swip all the menu items with crashing.

by James Tabor

jimtabor(a)svn.reactos.org wrote: > Clean up and fixed NtUserGetMenuItemRect. Needs more testing. I watch mplayerc swip all the menu items with out crashing. > > > Updated files: > trunk/reactos/subsys/win32k/ntuser/menu.c > *out

19 years, 9 months

Info about debugger

by Juan Rodriguez

what debugger can i use on ros?

19 years, 9 months

install problem

by Hartmut Birr

Hi, it seems, some people have problems to install reactos from the boot cd. The reason is, all newer pc with a P4-HT or an AMD64X2 cpu are multiprocessor compliant. In this case, the auto choice is multiprocessor for the computer type. If the choice isn't changed, the multiprocessor hal and the uniprocessor kernel are installed. The next boot will show an empty colored (light green or red) screen after freeldr has started reactos. I think, we should disable the auto choice for the computer type. - Hartmut

19 years, 9 months

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