Blue Screen on mounting

[Bodo Thevissen]

Hi,

during about 30% of the times mounting a non-boot disc fully encrypted my machine fires a blue screen (memory issue). This happens with the current version but started about 1-2 weeks before the current version was released.

It seems that this does happen more likely when the cores are close to being 100% busy (6 threads of 8 on a 4 core+multithreading).

This is my machine:
Win10 H2 64 bit (all current updates)
i7 6800k
16 GB DDR4 RAM (the RAM has been tested via the Win10 tool and is fine).

Any ideas? Should I provide a photo of the BSOD? Thanks in advance.

Cheers,
Bodo

[RealTehreal]

Hey there,

having a screenshot of the error would be the least to be able to provide help. So please create one, the next time, the issue occurs.

Additionally, when the issue came out of nowhere, without changing the system, it would more likely be a hardware issue. You should run memtest86+ for a day or two, to be at least to a certain extent sure, that the RAM is fine. But even then, it's not a given to detect all hardware issues. Detecting RAM issues can be a very time-consuming task.

Greets

[Bodo Thevissen]

Hi @RealThereal,

Will try to do the memtest test. The next time I tried to mount my volume while putting stress on the CPU it crashed so I have a screenshot.

Thanks for your help.

Cheers,
Bodo

[RealTehreal]

I had a look into the BSOD code. It seems that there are several possible reasons for this error. To possibly get some fast results, you should check the event log (method 6 of the following link). But you could try out all the other methods mentioned.

https://www.stellarinfo.com/blog/page-fault-in-nonpaged-area-error-on-windows-10/

You could also try to read the memory dump to find out the reason for the error code. But you should consult a Windows 10 forum for this - the guys on those kinds of forums are more specialized in such kind of things.

Greets

[Bodo Thevissen]

Thanks, method 5 is refering to the Windows internal memory test. I did this about 2 weeks ago (when the crashes occured several times) but this memory test didn't show any problems.

The crashes only occur when mounting the veracrypt volume and especially when there is stress on the CPU.
Close to this time I created this specific truecrypt volume. Perhaps something is wrong with the volume?

Will try to rule out all other reasons.

Edit: I ran 5 passes of complete memory tests with Memtest64 without any errors.

[RealTehreal]

Thanks, method 5 is refering to the Windows internal memory test. I did this about 2 weeks ago (when the crashes occured several times) but this memory test didn't show any problems.

Windows' memory test never shows any issues (as far as I can tell) - it's quite useless.

The crashes only occur when mounting the veracrypt volume and especially when there is stress on the CPU.

Maybe the memory became warm and faulty due to heavy usage? Just a guess - I actually do not know what you are doing.

Have you tried to mount the volume while the system is idle?

Close to this time I created this specific truecrypt volume. Perhaps something is wrong with the volume?

If there is something wrong with the volume, I wouldn't expect the system to go BSOD with memory issue error. It would be more likely to get an error from VeraCrypt or a corrupt filesystem message from the OS.

Edit: I ran 5 passes of complete memory tests with Memtest64 without any errors.

Faulty memory was my best guess. But no errors after 5 passes doesn't mean there are no memory issues. That's the nasty thing.
I'm currently in the situation that I get random system freezes. Sometimes I get memory errors from Memtest after 4 passes, sometimes no errors at all, even after 10 or more passes. Debugging memory issues is not a funny thing to do.

Greets

[Bodo Thevissen]

Hi again,

To give you slightly more insight: with 4 cores and 8 threads (thanks to multithreading) I am running 6 "lame mp3" conversions at the same time. So the CPU is kept 100% busy with:
- conversion of many rather small wavs to mp3 files
- Windows defender checking the lame mp3 executable with every start of it (eating about 10-30% of the cpu power)
- and then I dare to mount a veracrypt device consuming even more cpu cycles.

The only other rather special thing about my setup is that the newly created MP3 files are written to a RAM disk (created by ImDisk).

The BSOD only happen when Veracrypt is mounting and mostly when the CPU is under stress and/or writing to the RAM Disk.

So I could offer two theories:
1. the crash occurs when the cpu is stressed
2. the crash occurs when the device drivers for veracrypt and ImDisk intervene.

As a small sidenote I want to add that exactly this setup with all these tools has been working perfectly for many years. Except of course updates for each of them (plus windows) regularly.

I will run some tests trying to isolate the conditions that have to be met (keeping the cpu busy without writes to the RAM Disk or vice versa etc.).

ps. the RAM Disk should not be at its limit as it is able to write about 5 GB/s and those conversions won't get close to it. But perhaps the memory bandwidth itself comes to its limit?

[RealTehreal]

ImDisk could be another puzzle piece in pointing the BSOD issue down:
- Have you had a look at memory usage when the issue occurs? Maybe you are running low on memory because the RAM disk blocks too much memory, which is needed for other processes?
- Have you tried your workflow without using a RAM disk?
- Have you tried your workflow without using VeraCrypt at the same time?

From the time I was still using Windows, I remember that stuff like RAM disks made my system unstable. Possibly, that's the trade-off for a usage concept, that's not meant for the OS.

[Bodo Thevissen]

Have you had a look at memory usage when the issue occurs? Maybe you
are running low on memory because the RAM disk blocks too much memory,
which is needed for other processes?

There is no memory shortage. It happens with a lot of GB of free RAM.

Have you tried your workflow without using VeraCrypt at the same time?

Yes, it really only happens when mounting a Veracrypt volume.

Have you tried your workflow without using a RAM disk?

not yet, but will very soon.

[Bodo Thevissen]

started the tests:
[x] 10 mounts of the volume
[ ] 10 mounts with cpu stress via prime 85
[ ] 10 mounts of stress on the RAM disk

[Bodo Thevissen]

started the tests:
[x] 10 mounts of the volume
[x] 5 mounts with cpu stress via prime 85
[x] 5 mounts of stress on the RAM disk via crystal disk mark
[x] 5 mounts with 2 lame threads writing on the RAM disk
[x] 5 mounts with 4 lame threads writing on the RAM disk (cores still not 100% busy)
[x] 5 mounts with 6 lame threads writing on the RAM disk

All tests have been without any problem. The only "viarable" I didn't test yet was a java based tool that usually ran when the crashes occured.
I updated to the new Veracrypt version and will report if any more crashes occur.

[Bodo Thevissen]

the problem vanished. I have no clue where it came from and where it went.