Build: Difference between revisions
No edit summary |
No edit summary |
||
| Line 91: | Line 91: | ||
Kernel debugging can be enabled by editing the <code>C:\boot.ini</code> file in your installed build, and adding <code>/debug /debugport=COM1 /baudrate=115200</code> to the end of a config line. | Kernel debugging can be enabled by editing the <code>C:\boot.ini</code> file in your installed build, and adding <code>/debug /debugport=COM1 /baudrate=115200</code> to the end of a config line. | ||
For example here's a <code>boot.ini</code> with two choices, one with debugging & one without, with this NTLDR will show an OS boot choice menu at startup:< | |||
For example here's a <code>boot.ini</code> with two choices, one with debugging & one without, with this NTLDR will show an OS boot choice menu at startup:<syntaxhighlight lang="ini" line="1"> | |||
[boot loader] | |||
timeout=30 | timeout=30 | ||
| Line 101: | Line 104: | ||
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /fastdetect | multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /fastdetect | ||
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /fastdetect /debug /debugport=COM1 /baudrate=115200</ | multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /fastdetect /debug /debugport=COM1 /baudrate=115200 | ||
</syntaxhighlight>(even though they're named the same <code>Windows Server 2003, Enterprise</code>, NTLDR will add a <code>[debugger enabled]</code> tag to it on the OS selection menu.) | |||
<code>chk (checked)</code> builds are preferred for debugging as they enable asserts & debug messages, though <code>chk</code> will run a lot slower than <code>fre</code> builds. <code>fre</code> builds can also be debugged fine, but usually with a lot less debug output. | <code>chk (checked)</code> builds are preferred for debugging as they enable asserts & debug messages, though <code>chk</code> will run a lot slower than <code>fre</code> builds. <code>fre</code> builds can also be debugged fine, but usually with a lot less debug output. | ||
| Line 110: | Line 114: | ||
There is apparently a way to get KDNET working on 2003 too (see <nowiki>https://github.com/MovAX0xDEAD/KDNET</nowiki>), but this is as-of-yet untested with our builds, seems like it should have support for VMware's emulated network hardware at least. | There is apparently a way to get KDNET working on 2003 too (see <nowiki>https://github.com/MovAX0xDEAD/KDNET</nowiki>), but this is as-of-yet untested with our builds, seems like it should have support for VMware's emulated network hardware at least. | ||
=== VMware setup === | === VMware setup === | ||
| Line 132: | Line 134: | ||
Even with a chk build you may notice that the kernel doesn't seem to output much over KD, this seems to be because most of the kernel components use <code>KdPrintEx</code>, which allows filtering KD messages to certain components (although MS's docs seem to suggest KdPrintEx filtering was only used in Vista, it does seem that 2003 makes use of it too) | Even with a chk build you may notice that the kernel doesn't seem to output much over KD, this seems to be because most of the kernel components use <code>KdPrintEx</code>, which allows filtering KD messages to certain components (although MS's docs seem to suggest KdPrintEx filtering was only used in Vista, it does seem that 2003 makes use of it too) | ||
To enable components you'll need to open the registry of your installed build to the following key (or create it if it doesn't exist)< | |||
To enable components you'll need to open the registry of your installed build to the following key (or create it if it doesn't exist)<syntaxhighlight lang="registry"> | |||
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter | |||
</syntaxhighlight>Then create a DWORD value named the component you want to enable (e.g. <code>LDR</code>), and set the value to hexadecimal <code>FFFFFFFF</code>. | |||
A list of the component registry names can be found inside <code>base\published\obj\i386\dpfiltercm.c</code> after a build. This also contains the symbol names for the component (eg. <code>Kd_LDR_Mask</code>), which can be set directly through WinDbg/KD via the symbol name. (eg. <code>ed nt!Kd_LDR_Mask 0xFFFFFFFF</code>, with symbols loaded this should set the LDR components filter value in real-time) | A list of the component registry names can be found inside <code>base\published\obj\i386\dpfiltercm.c</code> after a build. This also contains the symbol names for the component (eg. <code>Kd_LDR_Mask</code>), which can be set directly through WinDbg/KD via the symbol name. (eg. <code>ed nt!Kd_LDR_Mask 0xFFFFFFFF</code>, with symbols loaded this should set the LDR components filter value in real-time) | ||
| Line 141: | Line 147: | ||
=== x64 build OS support === | === x64 build OS support === | ||
prepatched.zip v9 adds support for using x64 build OS's such as Win10 x64, this is done by wrapping certain 16-bit tools using <code>MS-DOS Player</code>, using .bat files to redirect calls to use the player, changing some makefiles to use 32-bit equivalents, etc. | <code>prepatched.zip v9</code> adds support for using x64 build OS's such as Win10 x64, this is done by wrapping certain 16-bit tools using <code>MS-DOS Player</code>, using .bat files to redirect calls to use the player, changing some makefiles to use 32-bit equivalents, etc. | ||
Unfortunately some of the wrapped 16-bit tools can still randomly error without rhyme or reason for it, as a workaround the .bat files of the worst offenders will give it 5 attempts before failing, hopefully this should be enough to allow builds to complete fine, but there's still a chance one of the other 16-bit tools could error too... maybe in future I'll apply this 5-attempts bandaid over all the 16-bit tools. | Unfortunately some of the wrapped 16-bit tools can still randomly error without rhyme or reason for it, as a workaround the .bat files of the worst offenders will give it 5 attempts before failing, hopefully this should be enough to allow builds to complete fine, but there's still a chance one of the other 16-bit tools could error too... maybe in future I'll apply this 5-attempts bandaid over all the 16-bit tools. | ||
| Line 147: | Line 153: | ||
Huge thanks to the anon who initially worked on fixing the 16-bit tools over at <nowiki>https://rentry.co/16bit-msbuild</nowiki>! | Huge thanks to the anon who initially worked on fixing the 16-bit tools over at <nowiki>https://rentry.co/16bit-msbuild</nowiki>! | ||
=== | === AMD64 build support === | ||
As of update v10 an amd64 build can be created by | As of update v10 an amd64 build can be created by initializing razzle with the <code>win64 amd64</code> options, the build should mostly complete without errors, but note that post-build+ hasn't been updated at all to work properly with amd64 yet. | ||
Unfortunately as the leak didn't come with exinit.obj/systime.obj for amd64 these need to be built from anon's decompilations instead. v10a adds newer exinit.c/systime.c decompilations that are apparently an exact match to the x86 .obj files included in the leak, hopefully these should work well with other architectures too. | Unfortunately as the leak didn't come with exinit.obj/systime.obj for amd64 these need to be built from anon's decompilations instead. v10a adds newer exinit.c/systime.c decompilations that are apparently an exact match to the x86 .obj files included in the leak, hopefully these should work well with other architectures too. | ||
Some | Some anonymous users from 4chan have been slowly working on AMD64 back in 2020, being able to get past text-mode setup and start booting GUI-mode setup, though sadly as of this release nobody has been able to actually get GUI mode to fully start up. | ||
Note that this source code is from around ~2 years before | Note that this source code is from around ~2 years before AMD64 was officially released by MS as Server2003 SP1, so there's likely a lot missing. (WRK may have some newer kernel-mode parts, being both based on SP1 and including support for amd64, though note that WRK also has many things removed too...) | ||
However there's also many indications in the leak that MS did have amd64 running at this point, so it should eventually be possible for us to get it working too. | However there's also many indications in the leak that MS did have amd64 running at this point, so it should eventually be possible for us to get it working too. | ||