Bluescreen after installing version 4.0.9

I just purchased the latest version of RAM disk (4.0.9), installed, was running for about an hour and got a blue screen. First one in a very long time, so.... I have a minidump file, I see that spvve.sys is on the stack (as reported by nirsoft's minidump analyser). That's as much as I can see. I found in google search that indicates this is from SoftPerfect RAMdisk and it said to upload the minidump.

Before this, I was running RAM Disk version 3.7 for a long time and never had a problem. I bought this because I will need it to move to Win10 1903 (I'm on 1803).

Am I on the right track here? I attached the file here. Anything else I should do?

Here's the export if that helps:

<?xml version="1.0" encoding="utf-8"?>
<ramdisk>
  <mount/>
  <boot>
    <item>
      <filesystem>3</filesystem>
      <clustersize>0</clustersize>
      <folders>
        <name>temp</name>
        <name>audacity_temp</name>
        <name>files</name>
      </folders>
      <letter>A</letter>
      <size>22000</size>
      <image>
        <filename></filename>
      </image>
      <savetoimage>false</savetoimage>
      <removable>false</removable>
      <label>ramdisk</label>
      <compressed>false</compressed>
      <autoflush>false</autoflush>
      <flushtime>0</flushtime>
      <hddemulation>true</hddemulation>
      <numanode>0</numanode>
      <specnuma>false</specnuma>
    </item>
  </boot>
</ramdisk>

You are right, the crash took place in one of the RAM Disk drivers, but it seems the underlying cause is faulty RAM. Here is a bit of info from the minidump:

Quote

MODULE_NAME: hardware
IMAGE_NAME: hardware_ram
*** Memory manager detected 60171 instance(s) of page corruption, target is likely to have memory corruption.

Try Windows Memory Diagnostic, following by Memtest86+ or Prime 95. Prime 95 may be easier to use, since it's a regular Windows application: run the Blend test for a few hours as explained in the referenced article.

It does look like there is a hardware issue.

Do you know how to force a minidump so I can see if I get these errors with the old ramdisk. What tool did you use to see those memory errors? Is it something I can use easily?

I want to uninstall the latest version and reinstall 3.7 which I've used for nearly a year without a problem. If that too reports these errors, then I'll believe it's my hardware. Otherwise, the timing of the new driver is too suspicious. I looked at prime95 but it has some complex online requirement that I don't want to mess around with.

Thanks for looking at the dump.

We use WinDbg for analysis, you can install it as a component of the Microsoft debugging tools. To see the full analysis enter the !analyze -v command.

In Prime 95 you don't need to join any online program, simply choose the Just stress testing option and then Blend.

By the way, even if the old version works okay (it may simply not encounter the existing hardware fault due to the differences between the old and the new versions), I do recommend that you test the stability of your PC. If it's a hardware issue, it can lead to more serious problems such as data corruption or incorrect results, depending on what you are doing.

Ok, as you suggested, I just completed the Windows memory test, which I set for the advanced mode. It ran overnight with no errors. I've run this before, when I bought the second 16GB ram about 2 months ago and tested it through the night then as well.

(I've now got the crash dump tool installed. How did you find that message about memory errors?)

When I couldn't run the v3.7 ramdisk with 22GB disk on Windows 1903 (plus sound driver for realtek was failing) I restored from an image backup to 1803. Then I figured, why not buy the latest version of the ramdisk and when it gets the sound driver issue solved, I'd upgrade to 1903 again.

So, I'm wondering, was this ramdisk change compatible with the newer windows systems? Also tested against older versions of windows, since that's what I'm running now, and it's with 1803 that I got the bugcheck. Does it detect it's on an older version? Could there be a conflict between the new driver with the older OS?

One other thing, at the time of the blue screen I had been working with a VMware virtual Win8 system that I had been having a problem getting bridge mode to work all the time. I also purchased (with the ramdisk) the Network Scanner. I had just that instant (of the blue screen) tried switching between nat and bridge mode, as I was not getting a dhcp ip address in bridge mode. I wanted to see what netscan had to say about it.

In the event log right next to the bugcheck with a timestamp of 1 second later is a message about vmnetbridge just starting up, I assume that had actually occurred before the bugcheck which was found after restart and logged then.

So, we now have 3 things going on, vmware doing some network changes, and ramdisk (which was not doing anything except possibly if temp/tmp was being used by something), and the network scanner.

Also in the event log, which I've seen before are disk errors logged for disk6, which is the ramdisk. I see this all the time:

Quote

The driver detected that the device \Device\Harddisk6\DR6 has its write cache enabled. Data corruption may occur.

That one occurred just after the reboot. But there are others, from before the new version of the ramdisk as well as after I restarted with the 3.7 reinstalled

Quote

The driver detected a controller error on \Device\Harddisk6\DR6

or in xml:

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Disk" /> 
  <EventID Qualifiers="49156">11</EventID> 
  <Level>2</Level> 
  <Task>0</Task> 
  <Keywords>0x80000000000000</Keywords> 
  <TimeCreated SystemTime="2019-07-21T14:18:08.556494700Z" /> 
  <EventRecordID>48814</EventRecordID> 
  <Channel>System</Channel> 
  <Computer>core5-PC</Computer> 
  <Security /> 
  </System>
- <EventData>
  <Data>\Device\Harddisk6\DR6</Data> 
  <Binary>0F00800001000000000000000B0004C00301000000000000000000000000000000000000000000008F03000000000000FFFFFFFF060000005800002200000000FF200A120A01200000000000F00000000000000000000000007B3FF589D7FFFF000000000000000000000000000000000000000000000000000000000000000035000000000000000000000000000000000000000000000000000000000000000000000000000000</Binary> 
  </EventData>
  </Event>

Now that does not seem like a hardware issue, more like some error with drivers. If I had been having memory errors, I'm sure that would have caused other crashes (in the last few months with 3.7 running solidly).

As many driver bugs tend to be timing issues, especially with locking down resources, is there a way to get the new driver to NOT use threads, which is another thing advertised that is different with 3.7 and 4?

And typically I set the option to harddisk mode, since that is needed to run the program hdtune which I used to test the speed of the ramdisk. Could it help to turn that off? I had that on during the crash, but I've got it off now.

I've also sent the bugcheck to microsoft, but I suspect that'll take some time for them to respond.

I guess I didn't actually send the minidump to microsoft, but to something called the microsoft community, but I got this response:

Quote

microsoft community

Hi,
The process that crashed was the IAStorDataMgrSvc.exe :
Owning Process ffffb609bd18f080 Image: IAStorDataMgrS
The IAStorDataMgrSvc.exe is a component of the Intel Rapid Storage Technology (Intel RST) driver so there may be a clash between the Ramdisk program and the IAStorDataMgrSvc.exe.

Consider updating the Intel RST driver or uninstall and reinstall the Intel RST driver using the latest version available for the chipset.
As a general precaution create a System Restore Point prior to changing storage drivers.
The following may be the latest Intel RST driver for the chipset: downloadcenter.intel.com/download/26759...

If the issue persists you may be able to disable the IAStorDataMgrSvc.exe

Note: This is a non-Microsoft website. The page appears to be providing accurate, safe information. Watch out for ads on the site that may advertise products frequently classified as a PUP (Potentially Unwanted Products). Thoroughly research any product advertised on the site before you decide to download and install it.

I also downloaded the WhoCrashed program, and it has this to say:

Quote

WhoCrashed

On Sat 7/20/2019 5:30:47 PM your computer crashed or a problem was reported
crash dump file: C:\Users\xxxxxxx\Desktop\ramdisk stuff\072019-5421-01.dmp
This was probably caused by the following module: spvve.sys (0xFFFFF8024FDC56E5)
Bugcheck code: 0x3B (0xC0000005, 0xFFFFF8024FDC56E5, 0xFFFFB280499A03A0, 0x0)
Error: SYSTEM_SERVICE_EXCEPTION
file path: C:\WINDOWS\system32\drivers\spvve.sys
Bug check description: This indicates that an exception happened while executing a routine that transitions from non-privileged code to privileged code.
This appears to be a typical software driver bug and is not likely to be caused by a hardware problem.
A third party driver was identified as the probable root cause of this system error. It is suggested you look for an update for the following driver: spvve.sys .
Google query: spvve.sys SYSTEM_SERVICE_EXCEPTION

Rocket777, are you sure you had RAM Disk version 3.7? I've been using SoftPerfect RAM Disk for 7 years, starting version 3.2, updating to every released version, and never seen version 3.7. It went from v3.4.8 to v4.0 when RAM Disk became commercial.

I have RAM Disk installed and heavily used on 3 computers: Win XP, Win 7 and Win 10. Every machine/OS went through all RAM Disk versions current at the time and never had any problems with any version of RAM Disk; except Windows 10 1809 when Microsoft broke memory allocation for large disks, but updating RAM Disk to a new version fixed that. So I can confirm that there is no problem in RAM Disk compatibility with older systems. The latest RAM Disk works on my Win XP, 7 and 10 perfectly well.

By the way, SoftPerfect are great in that they give free trials for all their products. Their software is of very high quality, but I still always download and test free trials before buying, to make sure there are no issues with hardware or some other software I have.
Instead of

buy > install > chase problems

my routine is

install > try > buy and be happy 

@rocket777

Sorry we are unable to determine the cause of your crash. We went through the crash dump again and even narrowed it to the line of code, but there is nothing suspicious there. It's a regular pointer cast to check some RAM disk's internal flags. The only way it can possibly crash is if something is wrong with that memory location.

Like you suggested above, there may be a compatibility issue with Intel's RST drivers, but we can't test it further without having your specific hardware and software combination at hand. If you happy to continue using the older version, we will give you a refund for the purchase (for that please submit a ticket to our support desk).

@Jan

Thank you for your feedback. That's indeed a good approach (we ask and actively encourage all users to try free trials before purchasing), and we are happy to hear that our apps work well for you for so many years - we work hard to polish and test everything. Having said that, incompatibilities do happen in rare combinations of hardware and software, like in Rocket777's case. I guess it's just unavoidable in the software industry.

Sorry, 3.4.7 I was being sloppy, really just trying to distinguish between the free and paid versions, since the paid version has a change to deal with large ramdisks working in a version later than 1803.

I'm running that version now. As for trial versions, I ran it for about 30 minutes and figured it looked so much like my 3.4.7 version that not too much would have changed and it appeared to work, so I bought it. I don't care about the $30 and won't be asking for a refund. I'm planning on staying with win 10 1803 until at least the realtek audio problem is fixed in 1903. My hope is that over the next year (of my paid updates) a problem will be found and fixed. Otherwise, I won't be able to go to 1903 as I've become quite fond of having a huge ramdisk. Not that I really care about 1903, but MS is getting pushy about updates. I'm back to blocking their updates for 365 days.

So much was going on at the time of the crash that it's difficult to say, except that the ramdisk was definitely on the stack at the time of the crash. The one analysis says that the problem was in a routine that changes between non-privileged code to privileged code. I believe it's most likely some clash between vmware and ramdisk, as it's just too coincidental that within a second of trying to change from nat to bridge mode, the system crashed. As I discovered yesterday, and posted in the scanner section, the problem with bridge mode was from a setting that had it looking to bridge the Npcap Loopback Adapter, and that sure sounds like a driver to me. I'm not sure how that setting even happened.

I've also seen errors in the event log for a long time. These sound like something in the disk subsystem doesn't like something the ramdisk is doing, as opposed to actual hardware errors. I even saw them before I got an extra 16g of ram. I don't know what those errors are about. I saw them for both the old and the new driver. But I wasn't getting any bluescreens.

I don't know how much windows still looks like Dave Cutlers's original win NT anymore, but years ago I wrote device drivers for Cutler's old DEC os's. The name bugcheck comes from that. So, if there's still any resemblance, I recall the most common problem was trying to do things at the wrong interrupt priority level. I always felt it was a tangled mess. I suspect that thread support didn't make that any cleaner. That's why I was wondering if there was a way to disable the new speedups from using threads. When I test the ramdisk with hdtune I see no particular speed difference between 3.4.7 and the latest versions. I don't know if in 1803 threads are used in the ramdisk, or if that starts with a later version of windows.

Yet, I now have 3 explanations as to what the problem was. I'm not complaining, I hope this gets fixed. But I don't want to experiment with the new driver over the next year, blue screens can cause nasty problems with data corruption.

Quote

Andrew

The only way it can possibly crash is if something is wrong with that memory location.

Are you certain that it's not just a memory protection issue? The one analysis said it happened while trying to get to a more privileged mode.

Here's what I found running windbg:
---------------------
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.

FAULTING_IP:
spvve+56e5
fffff802`4fdc56e5 8b01 mov eax,dword ptr [rcx]

BUGCHECK_STR: 0x3B_c0000005


And looking that up:

Bug Check 0x3B SYSTEM_SERVICE_EXCEPTION - Windows drivers ...docs.microsoft.com/.../drivers/debugger/bug-check-0x3b--system-service-exception

CauseResolutionRemarks

The stop code indicates that executing code had an exception and the thread that was below it, is a system thread.The exception information returned in parameter one is listed in NTSTATUS Values and is also available in the ntstatus.h file located in the inc directory of the Windows Driver Kit.One possible exception value is 0xC0000005: STATUS_ACCESS_VIOLATIONThis means that a memory access violation occurred.
---------------------

In lieu of a refund, I would prefer say, extra free updates, is that permitted? Until MS forces me to update, I'll just stick with 3.4.7 and check back here over time to see what new versions have to say.

It just occurred to me that with fixing my VMware bridge issue, I won't have to switch to nat and back. So if indeed there's a conflict there, I should not have to do that again, and perhaps not have any more issues.

I would like to make one last suggestion (I promise) : to have a setting to disable the threading code that's been added recently. If I do get another crash, I could then check if that makes a difference.

So, I'm back on the new driver and I've upped my backup schedule to 2 incremental image backups a day

I won't be back unless I have another crash dump.

Good to hear you found some solution!

Personally I've never used RAM Disk with bridging in VMware, so I can't comment on that. But it does look like it may easily be the culprit, especially when Win8 & Win10 are involved . My personal experience is such that in 7 years no matter which OS and machine I installed RAM Disk on, I've never seen any errors (with one exception I noted above, which was of Microsoft's own making), let alone blue screens.

Also, I wouldn't be relying too much on the crash and error log info. RAM Disk is a sophisticated arrangement stretching deep into machine's operations and changing the way software products and hardware operate, so any issues with any of those may appear as if RAM Disk is "guilty" when in fact it isn't.

Quote

rocket777

I would like to make one last suggestion (I promise) : to have a setting to disable the threading code that's been added recently. If I do get another crash, I could then check if that makes a difference.

If you are referring to the change in version 4.0.9 mentioned in the changelog as "Improved: up to 2x performance increase in multithreaded I/O", then please try version 4.0.8, which is the version before that change was made, and let me know your observations.

Thanks for the link. It's been about 3 weeks without a problem. I'll save your older version, but I'm not having any issues. It must have been a problem with the VWware changes I made. Rock solid so far. As long as it ain't broke I won't need to fix it. I'll keep the older version in case something does happen.

Thanks again.