10 BSODs with Beta v763

[JoeS]

Hi,

 

it seems since updating to 763 I got 10 of BSODs in the last 20 Days.

 

All are IRQL_NOT_LESS_OR_EQUAL and with ntoskrnl.exe as the Adress in Stack.

 

I also just opened a minidump file with WinDBG and used !thread, here covefs is mentioned a few time (with not much else). I recently transfered some data (1-2TB) from another drivepool to a an older one.

 

I just updated my drivepool to 773, but I figured you guys maybe want to to look into it? Should I upload my .DMP files? If yes, where to (it's 741KB big)?

 

 

[JoeS]

I just uploaded them to the "StableBit DrivePool 2.X File Submissions" Dropbox form

[Christopher (Drashna)]

Well, you shoudn't be using this build.  As it's not a numbered build, that means it's an interim build and likely not stable. 

 

Try this version and see if it helps:

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

 

Also, try running a memory test on the system, just in case.

http://wiki.covecube.com/StableBit_DrivePool_Q537229

[JoeS]

Hi,

 

how do I know if it is numbered? When it is mentioned in the changes.txt?

 

Thx,

Joe

[Christopher (Drashna)]

Yes.  By "numbered", I mean that the build number is actually mentioned in the change log. 

 

 

For instance:

 

 

.774
* After removing a missing disk, check for meaningless pattern limits and invalidate measurement data.
.773
* Bug fixes and usability tweaks to the file placement UI.
.772
* Got rid of the troubleshooting start menu shortcuts. Use DrivePool.UI.exe /? for command line options.
* Reorganized the Pool / Settings menus.
* The Troubleshooting menu is now always visible.
* [issue #17740] Added verify after copy to the Troubleshooting menu (it will default to DrivePool_VerifyAfterCopy).
.770
* [issue #19772] File backed virtual drives cannot be added to the pool.

 

774, 773, 772, and 770 are all numbered builds.  And 771 is not.  

 

Also, the second numbered build is the best to use, as it should be more stable. (so in this example, 773 is the build that you'd want to use).

 

 

The unnumbered builds are builds that are still "in flux".  Meaning that Alex is still testing things out, and they may have incomplete code, or unstable code.   Because of this, these builds are MUCH more likely to crash or have weird issues.