Hyper-V BSOD

[Michael Vickers]

I'm posting this info in case anybody else runs into the same thing.

 

Host: Win2k8R2 x64 running DrivePool 2.1.1.561

Guest: Win2k8R2 x64

1. In Disk Management on the host computer map the DrivePool disk to a path. Here is an example where I've mapped my DrivePool disk to a path on the C drive (it's the second entry): https://www.dropbox.com/s/ns93g4guhaoae3m/Screenshot%202016-09-24%2014.43.41.png?dl=0.
2. Share the folder containing the path. In my example I'm sharing C:\Volumes which contains the "P1" folder which is mapped to the DrivePool disk.
3. In the guest machine either map a drive to that host share or browse the host share without mapping a drive.
4. Browse into the DrivePool disk on the share.
5. Create a new folder and give it a name.
6. BSOD occurs in covefs.sys on the host.

In my setup when I create the folder the BSOD occurs immediately. When I reboot and go to rename the folder the BSOD occurs again and the folder does not rename. 

 

The workaround is to share the DrivePool disk directly. For me the error does not occur when I map the DrivePool disk to a letter (in my example drive "P") and then share that drive letter in the host.

[Christopher (Drashna)]

Does the BSOD occur on the latest beta build?

http://dl.covecube.com/DrivePoolWindows/beta/download/StableBit.DrivePool_2.2.0.708_x64_BETA.exe

 

And if so, could you grab the crash dumps from the BSODs?

http://wiki.covecube.com/StableBit_DrivePool_System_Crashes

[Michael Vickers]

Hi Christopher.

 

Thanks for the reply. I just got this array set up and stable on new hardware last week after a lot of headaches. I'm hesitant to run beta software on the server now while trying to trigger a bsod and not turn the array into scrambled eggs at the same time. I'm content to run with the workaround for the time being and watching to see if 1) you folks can replicate the error and 2) issue a fix for it.

[Christopher (Drashna)]

I absolutely understand not wanting to run Beta software.  

 

Though, the beta builds are usually pretty stable, and address a lot of issues. They're just not as well tested as the stable releases.  But chances are, the issues you're seeing may be fixed in the newer versions (there are a number of issues that have been fixed that could cause BSODs).

So, it's easier to recommend the latest build and see if the issue occurs, rather than troubleshooting an issue we've already fixed.  That's why I link these builds. 

 

 

As for the crash dump, we're not wanting you to trigger them. We just want you to grab the crash dumps, that are created when the system has BSODed (these are written out normally, and is why BSOD's don't immediately reboot)

 

So if you could check to see if "C:\Windows\MEMORY.DMP" exists on the system, and grab that, that's all we want. 

 

 

 

Actually, reviewing it, based on what you've said, I suspect that this is the issue specifically: 

.695
* [D] Querying for a file ID on the root directory would incorrectly modify the file name to be blank. Subsequently, opening another 
      handle to the root directory using a related file object (with the previously modified file name) and a blank file name would 
      incorrectly result in trying to open a blank file name. This would end up raising an invalid parameter error.

Otherwise, following your instructions, I'm not able to produce a BSOD. 

[Michael Vickers]

Thanks. I've uploaded the last memory.dmp to dropbox, under my name.

[Christopher (Drashna)]

Thanks.

 

From the looks for it, the BSOD may have been caused by an interaction between the network share, DRivepool, and "MirrorFolders" (and specifically, this last one), as these are what were being called right before the BSOD. 

 

So if the issue is still occurring, let us know.