after building a BIOS for the motherboard to support a CPU that it does not support 'yet' ...
it's time for Scope or so i thought – and handed Claude v5.1 driver - as we know it gives bluescreens with VDAT, samplers and what not, also it fails to pass Windows audio (garbage on inputs), and XTC mode is very, very temperamental - like, works 1 time out of 10 - yes, nine bluescreens, you're right.
that's what Claude said:
I disassembled the driver and found a genuine bug — and confirmed it isn't just "compiled 32-bit" (it's a real PE32+/x86-64 binary, machine type AMD64, built 2010-11-23). Embedded debug strings identify it as Sonic Core's SCOPE/Pulsar Multichannel audio driver, built from d:\scope 5.1 source\Src\vxd\win2k\x64\Release\scScope.pdb — a Win2K/VXD-era codebase later ported to x64, which lines up with your "ported and patched over the years" description.
The good news first: the parts that talk directly to the hardware are done right. MmAllocateContiguousMemorySpecifyCache (the card's DMA buffer) is explicitly capped to physical addresses below 4 GB, which is exactly correct for a card whose DMA engine only understands 32-bit bus addresses. MmMapIoSpace for the PCI BAR also uses a proper full 64-bit physical address. So the hardware-facing DMA logic isn't your problem.
The actual bug: in the per-channel/stream buffer setup routine (around VA 0x180008675, tagged with pool tag 'GSIF'), the driver calls ExAllocatePoolWithTag, gets back a real 64-bit kernel pointer in RAX — then stores only the low 32 bits of it into a 4-byte-wide array slot in its device extension (mov DWORD PTR [ctx+i*4+0x100], edx — a *4 stride, i.e. a leftover ULONG[] array that should be a pointer-sized array on x64). It then reads that same slot back, zero-extends the truncated value into a 64-bit register, and immediately does a rep stos (a memset/RtlZeroMemory) to that bogus reconstructed address. Since NonPagedPool addresses on x64 always live way up in the high canonical range, truncating to 32 bits never gives you the real buffer — it gives you an essentially arbitrary low address. Whether that write immediately faults (instant BSOD) or happens to land on other mapped memory (silent corruption → a random, delayed BSOD later) depends on the pool layout at that moment, which is exactly why it happens "sometimes" rather than every time. The same truncation happens a second time nearby and also leaks into another table used elsewhere in the driver. Interestingly, other parts of this same driver correctly use 8-byte-stride pointer arrays — so this looks like one specific spot that got missed during the x86→x64 port, not a systemic "still 32-bit" design.
I put the full technical write-up (exact addresses, disassembly excerpts, and a fix recommendation) in the file above. Short version of the fix: if you have the source, find the device-extension field around offset 0x100 that's declared ULONG/DWORD but holds a pointer from that 'GSIF' allocation, retype it to PVOID/ULONG_PTR, and audit the sibling MIDI/wave/topology allocation paths for the same pattern — it's a struct-layout issue, so it isn't something that can be safely binary-patched without the source.
the complete analysis: https://audiomastering.lt/scScope_x64_analysis.md
---
why not version 7 you may ask? well, i found it decapitated - XTC broken completely, some other 'old stuff' is also broken - and not sure what's the positive takeaway from that version. maybe it's possible to fix even that but anyways --- we need source code rather than doing random binary patches
!!!
