`Box` allocations lead to BSOD: PAGE_FAULT

[balenamiaa]

let rw_buffer = Box::new([0u8; align_size(NONPAGED_BUFFER_SIZE)]);
let rw_buffer: Box<[u8; align_size(NONPAGED_BUFFER_SIZE)]> = unsafe { Box::new_uninit().assume_init() };

Both of these fails. ExAllocatePool2 with the same size succeeds. Using alloc directly also succeeds:

let rw_buffer: *mut u8 = unsafe { alloc(Layout::new::<[u8; align_size(NONPAGED_BUFFER_SIZE)]>()) };

It's probably the cause I am not understanding something, but if that's so, I think it's important it's documented.

[wmmc88]

How big of a buffer are you trying to allocate (ie. What does align_size(NONPAGED_BUFFER_SIZE) evaluate to)? What BugCheck code are you getting?

I did a quick test with let rw_buffer = alloc::boxed::Box::new([0u8; 100]); and was not able to repro

[balenamiaa]

I haven't debugged further to see what bugcheck code I was getting. NONPAGED_BUFFER_SIZE is 458696 bytes. I will debug further and create a repro when I can

[wmmc88]

I'm guessing that you're overflowing the stack, since you're constructing the array on the stack and it gets moved to the heap by the box constructor. In release builds, that might get optimized away, but there's no guarantee. AFAICT, you're running into rust-lang/rust#53827

That upstream issue lists some possible ways to avoid this (ex. into_boxed_slice). You could also consider using alloc::vec::Vec itself

[balenamiaa]

True, the kernel stack size is more limited. I had assumed new_uninit wouldn't stack allocate, but in retrospect it might(does).

Thank you for your time!