hi!

the two instructions are mov eax,4 and mov cr0,eax.

i was playing with grdb, a real mode debbugger, and i launched it under windows (why? dunno...)

important, i had a winamp running.

i started typing commands in, and i tried to set cr0.PE to 0, and it didnt work, and i tried to write a random value namely 10) to it (into eax first), and grdb wrote 10h into eax, and i thought "i meant 10D!!!" and i wrote 10d (you re already laughing) and it wrote 10Dh into eax, but i moved it to cr0 anyway, and at that precise moment my speakers freezed (well, they bzzz'ed for half a second) and i was standing in front of my videocard's bios screen. yes, it rebooted.

after many tries and many reboots (maybe ten, maybe more...) i isolated the triggering events.

setting cr0.em (emulation) (bit 2) while having sound playing in another thread is enough.

the intel manuals state cr0 is no writable in v86 mode, i think. it seems some bits are.
after setting it in grdb (without winamp running) and reading cr0 again, it IS set.

cr0.em set to 1 means an fpu opcode shall generate an exception, where it can be emulated, so i first thought it was something like cr0 not being preserved between task switches,and winamp executing fpu or mmx(i guess i m triple faulting the cpu), so i wrote a COM (dos) program (copro.com) that wrote 1 to cr0.em, waits a key, and resets it.

i have written 2 other COM programs that execute mmx and fpu, and i launch them simultaneously with the copro.com, and it doesnt crash.

the program must play sound. i launch copro.com, then a demo with disabled sound, it doenst crash, then the same demo with sound enabled, it crashes.it crashes with every sound prog i tried, except the windows "event" sounds ("ding!"etc).it doesnt crash with winamp STOPPED, but it DOES win winam PAUSED.(!)

i am aware it may only be a driver problem that only occurs on my system.

but why?cr0 shouldnt have to be preserved between tasks since its task-independant.it shouldnt be writable either in V86 but i see it is. even more strange, if i launch two sessions of grdb, i can set cr0.em in the first, and it doesnt change the other , the two tasks have an independant cr0 (which is maybe normal after all, but then why does it crash?)

maybe i ve got to try with a non-V86 task like a win32 PE prog, because maybe its only related to the NT VirtualDosMachine subsystem...but while writing to cr0 in V86 may be silent, wont it trigger some exception in 32b protmode when not ring0?

what do you think of this?

i would like to know if it does the same on other systems,maybe its a windows task isolation hole, but test it only if you accept to crash your windows and to see "the system has recovered from a serious error" at reboot, with sometimes a scandisk. i m not responsible for anything!

if you re like me and you dont care, tell me if it happens on your system!
i attach the files...
Posted on 2004-04-05 17:04:26 by HeLLoWorld
This sounds most disturbing.

Hm, I don't think CR0 would be included in a task switch, off top of my head I can't think of any reason why it should be. "Never say never", though.

Hm, and v86 tasks being allowed to overwrite CR0? I really hope that what's really happening is that XP's VDM emulates access to those bits of CR0 that can safely be emulated.

None of this would explain the crash, though. What's the BSOD error message? (If you have automatic reboot on crash, could you turn it off?). Information on the component where the crash happens could also be interesting.
Posted on 2004-04-05 17:26:48 by f0dder
doesn't work here - or rather, it works, instead of crashing :)

win2k+sp4, winamp 2.91, creative soundblaster audigy + whatever drivers.

So it might be an XP problem, or a driver problem, or... anything else :)
Posted on 2004-04-05 17:33:37 by f0dder
tested it on another pc , doesnt crash, must be my system+drivers...

board: ecs k7s5a
proc:athlonxp 1700+
chipset:SiS735
audio:c-media ac97

deep_blue_screen info:
trap_cause_unknown
stop:0x00012(0x0001,0x000,0x000,0x000)

i tried to only load cr0 into eax in a 32b PE, it triggers an exception (priviledged instr).
so it must be the ntvdm that simulates the ability to write to cr0.em.

but even if its a carelessly designed sound driver, i dont see why it interacts with a v86 task...

what do you think?
Posted on 2004-04-06 12:27:51 by HeLLoWorld
hmmm, this does sound very strange indeed :) - I guess I should test on one of my kid brothers' XP boxes (one has onboard audio, the other has a TerraTec xfire1024).

I guess drivers might need to interact with ntvdm to provide soundblaster emulation for dos apps? That's just a *wild* guess and probably 100% wrong, though.
Posted on 2004-04-06 12:49:32 by f0dder