short quantums win 24H2

## How to revert short short quantums win 24H2 settings to what it was on win11 22H2/23H2

You'll need 2 boxes.
PC1 is the Target Box (you'll need to configure it via bcdedit).
PC2 is the Debugger Box (you'll need to install WinDbg on it, and also note its IP).


### First, set things up on the Debugger Box.

1. Download and install Windbg: https://aka.ms/windbg/download.
You can extract url from the downloaded package and then extract files from the archive using 7-zip if you don't want to do "real" installation.

2. Configure symbols. Just run this command as admin:
setx /M _NT_SYMBOL_PATH C:\stuff\symbols\local;srv*c:\stuff\symbols\ms*https://msdl.microsoft.com/download/symbols

And run this as regular user:
mkdir C:\stuff\symbols\ms

3. Launch WinDbg.
File / Start debugging / Attach to Kernel (Ctrl+K).
Use "Net" tab. You can leave port 50000 as is. Set [encryption] key to e.g. "j.e.f.f", w/o quotes.
Leave Target IP empty. Set flag "Break on connection". Press "Ok".

4. Run ipconfig and note IP of this box.


### Second, configure the Target Box.

From admin cmd configure old black boot menu (for simplicity):
bcdedit /set {bootloadersettings} bootmenupolicy legacy
bcdedit /set {resumeloadersettings} bootmenupolicy legacy
bcdedit /set {current} bootmenupolicy legacy

Now make copy of current item to enable timeout:
bcdedit /copy {current} /d "backup entry"
bcdedit /timeout 7

Now configure debugger:
:: /debug on might not work, but you can ignore that, see below
bcdedit /debug on
:: enter IP of the debug box instead of 192.168.555.777
bcdedit /dbgsettings net hostip:192.168.555.777 port:50000 key:j.e.f.f

:: [RARE] If you have multiple network cards on the target box and debugger doesn't connect:
:: find "bus.device.function" (e.g. 0.9.0) in the devmgmt.msc under "Location Information" for the netcard you use, enter it:
::bcdedit /set {dbgsettings} busparams 0.9.0

:: [RARE] Windows might not support your target box network card for kernel debugging.
:: It won't give you any warning or anything, kernel debugger just won't connect.
:: To check if netcard is supported, check VerifiedNicList.xml, or see
:: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/supported-ethernet-nics-for-network-kernel-debugging-in-windows-11
:: Having unsupported adapter would suck; sure there are other ways to do kernel debug, but your first fallback
:: would be to use separate PCI-E network adapter ($5 to $10).


### All done.
Now just reboot the Target Box.
You'll see boot menu with 7 seconds timeout. If entry has "[debug]" suffix, just press enter. Otherwise, just select debug mode manually for this boot session only: press F8, down-down-down, select "Debugging Mode".

Now Target Box should stop and you can examine its state on the Debugger Box.
Move to the Debugger Box and enter commands:
ba w4 nt!KiVelocityFlags "ed nt!KiVelocityFlags (dwo(nt!KiVelocityFlags) & ~40000)"
g

That'll set breakpoint on writing to KiVelocityFlags var, and force debugger to clear ShortThreadQuantum bit.
Debugger might stop with spurious "Break instruction exception", just press F5 to continue.

Now target should be running and once it boots you can do experiments.

You can press Ctrl+Break in debugger to stop the target at any moment.
You can remove your breakpoints with "bc *" command, although that shouldn't affect things.

You can display current velocity variable or "quantum end timer increment":
dd nt!KiVelocityFlags L1
dd nt!KeQuantumEndTimerIncrement L1

If VelocityFlags were edited correctly, KeQuantumEndTimerIncrement shall contain value 0n156250. On vanilla 24H2 system value would be 0n17400.
Anyway, that might or might not "adjust back" some performance to the way it was on win11 22H2/23H2. After all, it's just one of the many changes in that kernel.