Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk> writes: > On 11/06/2021 19:22, Alex Bennée wrote: > > (added Gitlab on CC) > >> Paolo Bonzini <pbonz...@redhat.com> writes: >> >>> On 11/06/21 17:01, Programmingkid wrote: >>>> Hello Alex, >>>> The good news is the source code to Windows XP is available >>>> online:https://github.com/cryptoAlgorithm/nt5src >>> >>> It's leaked, so I doubt anybody who's paid to work on Linux or QEMU >>> would touch that with a ten-foot pole. >> Indeed. >> Anyway what the OP could do is run QEMU with gdb and -d nochain and >> stick a breakpoint (sic) in breakpoint_invalidate. Then each time it >> hits you can examine the backtrace to cpu_loop_exec_tb and collect the >> data from tb->pc. Then you will have a bunch of addresses in Windows >> that keep triggering the behaviour. You can then re-run with -dfilter >> and -d in_asm,cpu to get some sort of idea of what Windows is up to. > > I have been able to recreate this locally using my WinXP and it looks > like during boot WinXP goes into a tight loop where it writes and > clears a set of breakpoints via writes to DB7 which is what causes the > very slow boot time. > > Once boot proceeds further into the login screen, the same code seems > to called periodically once every second or so which has less of a > performance impact. > > > This gives a repeated set of outputs like this: > > ##### bpi @ 0x90 > ### dp7 add bp inst @ 0x8053cab8, index 1 > ##### bpi @ 0xa4 > ### dp7 add bp inst @ 0x8053cab8, index 2 > ##### bpi @ 0xff > ### dp7 add bp inst @ 0x8053cab8, index 3 > ##### bpi @ 0xf
That's weird - maybe this is a misunderstanding of the x86 debug registers but it looks like it's setting each one to all the same value. > ### dp7 remove bp inst @ 0x8053f58a, index 0 > ##### bpi @ 0x90 > ### dp7 remove bp inst @ 0x8053f58a, index 1 > ##### bpi @ 0xa4 > ### dp7 remove bp inst @ 0x8053f58a, index 2 > ##### bpi @ 0xff > ### dp7 remove bp inst @ 0x8053f58a, index 3 > ... > ... > ### dp7 add bp inst @ 0x8053c960, index 0 > ##### bpi @ 0x90 > ### dp7 add bp inst @ 0x8053c960, index 1 > ##### bpi @ 0xa4 > ### dp7 add bp inst @ 0x8053c960, index 2 > ##### bpi @ 0xff > ### dp7 add bp inst @ 0x8053c960, index 3 > ##### bpi @ 0xf > ### dp7 remove bp inst @ 0x8053c730, index 0 > ##### bpi @ 0x90 > ### dp7 remove bp inst @ 0x8053c730, index 1 > ##### bpi @ 0xa4 > ### dp7 remove bp inst @ 0x8053c730, index 2 > ##### bpi @ 0xff > ### dp7 remove bp inst @ 0x8053c730, index 3 > ... > ... I wonder if this is Windows check pointing itself by observing when it gets to a particular place in the boot sequence. I guess we don't have any symbols for the addresses it's setting? > > From a vanilla XP install the 2 main sections of code which alter the > breakpoint registers are at 0x8053cab8 (enable) and 0x8053f58a > (disable): Ahh I misread - so those are the addresses of the routines and not where it's sticking the breakpoint? I notice from a bit of googling that there is a boot debugger. I wonder if /nodebug in boot.ini stops this behaviour? https://docs.microsoft.com/en-us/troubleshoot/windows-server/performance/switch-options-for-boot-files -- Alex Bennée
