Crashes on boot with a familar BSOD!

[jon_k]

Pertaining to reactos0.2.9-REL-live

It's so good at emulating Windows it seems to be emulating the BSOD too!

Click to enlarge
[ external image ]
I booted the computer up using the LiveCD and it took a while and did nothing at a blank screen until finally a BSOD appeared. I set the BIOS to have the CD as the first boot priority, and all the others were set to NONE (for the live CD)

I'm a bit miffed cause I gave up 110 days of Linux uptime to try out this liveCD and it was all for naught.

Think it's my hardware? I'm running an AMD 2600 XP with a VIA chipset. (Soyo Dragon KT333 motherboard if I remember correctly)

Here's the list of hardware I'm using (as seen from LSPCI on linux)
0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333]
0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333 AGP]
0000:00:09.0 Ethernet controller: Linksys NC100 Network Everywhere Fast Ethernet 10/100 (rev 11)
0000:00:0a.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07)
0000:00:0a.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 07)
0000:00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
0000:00:0e.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 50)
0000:00:0e.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 50)
0000:00:0e.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51)
0000:00:0f.0 RAID bus controller: Triones Technologies, Inc. HPT366/368/370/370A/372 (rev 05)
0000:00:10.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10)
0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8233A ISA Bridge
0000:00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
0000:00:11.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 23)
0000:00:11.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 23)
0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 If [Radeon 9000] (rev 01)
0000:01:00.1 Display controller: ATI Technologies Inc Radeon RV250 [Radeon 9000] (Secondary) (rev 01)

processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 10
model name : AMD Athlon(tm)
stepping : 0
cpu MHz : 1149.929
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx mmxext 3dnowext 3dnow
bogomips : 2277.37

[ScoTTie]

You should test it out in VMware/QEmu. Seeings most of the developers will test with them, the hardware they simulate will almost always work with releases. They also let you keep your precious uptime

[menn]

there should be a crash-on-boot** faq, for now anyway. i'll be working on something like that, but the only one i remember off the top of my head is:

if you change stuff in your qemu image you may mess it up and have to unzip qemu again

that of course only applies to qemu, there are other crash-on-boot issues, with the install but also with the live-cd (the ones with the live cd might be the most important. you can't change the files on a cd made from an iso all that easily.)

**i'm talking strictly boots that do take place and crash in the middle, not peripheral issues like "you burned your iso as a file, not an image" etc. crash-on-boot is still common enough to have a troubleshoot list of its own, would make newbie testers (like me!) very happy, must faster, and even keep this forum a bit more clear of debris

[lXciD]

I got BSOD too. But mine is abit different.

I downloaded the LiveCD and burn it using Alcohol 120% with Image Burning Wizard.

After that I boot it with on my friend laptop (ACER TravelMate 4001LMi). Then I got BSOD.

Here's the BSOD text.

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 (0xc0000005, 0x80021e3d, 0x00000000, 0x00000030)

*** ntoskrnl.exe - Address 0x80021e3d base at 0x80000000, DateStamp 0x0

Page Fault Exception: 14(0)
Processor 0 CS:EIP 8:80021e3d <ntoskrnl.exe:21e3d>
cr2 30 cr3 1dced000 Proc: 808d9c48 Pid: d8 <explorer.exe> Thrd: 808e3ae8 Tid: dc

DS 23 ES 23 FS 30 GS 0
EAX: 9f0d5c78 EBX: 8094a8e0 ECX: 8080c4d0
EDX: 00000000 EBP: 9f0d5c20 ESI 9f0d5c78 ESP: 9f0d5b4c
EDI: 00000004 EFLAGS: 00010282 kESP: 9f0d5b4c kernel stack base 9f0d3000

Frames:
<ntoskrnl.exe 21fe6>
<\??\E:\reactos\system32\win32k.sys: 611b7>
<\??\E:\reactos\system32\win32k.sys: 4db3e>
<\??\E:\reactos\system32\win32k.sys: 4dbb7>
<\??\E:\reactos\system32\win32k.sys: 7606c>
<\??\E:\reactos\system32\win32k.sys: 4c9b5>
<\??\E:\reactos\system32\win32k.sys: 4fe09>
<\??\E:\reactos\system32\win32k.sys: 4ff08>
<\??\E:\reactos\system32\win32k.sys: 4ff54>
<ntoskrnl.exe: 56ac9>
<7FFE0304>



Whew... long typing

[lXciD]

Okay, I was able to get the Live CD on my laptop working. My laptop is IBM R40.

[steveh]

It's really funny that reactos developers have chosen the same colour for their kernel crash screen, as a well known other product...

I personally would have preferred a shocking "red screen" with yellow text for reactos crash debugging. Or a yellow screen with red text.

Reactos should in this domain proudly distinguish from the "other". The "blue screen" reputation is simply too bad.

Maybe a developer reveals me in this thread where to change the colour codes. I would immediately do that on my source repository...

[TiKu]

I personally would have preferred a shocking "red screen" with yellow text for reactos crash debugging. Or a yellow screen with red text.

Well, this would have a big advantage. You'll see only one kernel crash of ReactOS in your life: You'll be blind afterwards.

[Matthias]

I personally would have preferred a shocking "red screen" with yellow text for reactos crash debugging. Or a yellow screen with red text.

Microsoft chose the colour very well. Blue is said to have a calmative effect on humans, and think that this is just what people need after a kernel crash

[TOTMS]

It's really funny that reactos developers have chosen the same colour for their kernel crash screen, as a well known other product...

I personally would have preferred a shocking "red screen" with yellow text for reactos crash debugging. Or a yellow screen with red text.

Reactos should in this domain proudly distinguish from the "other". The "blue screen" reputation is simply too bad.

Maybe a developer reveals me in this thread where to change the colour codes. I would immediately do that on my source repository...

That has been changed now. Also the default resolution in current svn vuilds is 800x600 with a -safe option in case existing hardware cant support that resoltion. (If the devs implemented my suggestions on bug #000 )

[menn]

arachne crashes with a nice skull and crossbones.
there's an idea, why not add a postcard from bikini atoll and pictures of fanatics with "the end is nigh" signs?

actually i almost never see the blue screen. a couple times a year. i don't think about it much, but i might have set it to red in system/win.ini because i'm one of those people that likes mainstream scifi. in any case, of all the things to keep the same, the blue screen doesn't seem that odd. it's almost like hearing someone say "hey weird, you kept the start button?" well, ya...