openzfs VS windows-driver-docs

Heads up, installing both WinBTRFS and OpenZFS on Windows may have problems:

"Win OpenZFS driver and WinBtrfs driver dont play well with each other"

https://github.com/openzfsonwindows/openzfs/issues/364

I tried it a few months ago and ReFS ate my data. No indication of why in event logs or SMART data. It had IsPowerProtected set because I have a UPS and I had a unclean restart, I would expect it to lose data, but not to corrupt the filesystem metadata. I had a backup of the data but wanted some recent changes. Refsutil (the official Microsoft tool) didn't help because it has not been updated for the newest ReFS version. I couldn't read most files because I had integrity enable and files failed the check. Hetman's Data Recovery was able to recover most of the data. In later testing I found out that IsPowerProtected is just very unsafe. I have since put some time into testing and sometimes fixing https://github.com/openzfsonwindows/openzfs , it is not ready for use yet, but it is making great progress.

Windows lacks support in the same sense that Linux lacks support; there are external projects implementing it for both, though I believe the Windows port is less polished. (Some people are running it in production, though...)

This is really cool and speaks to the modularity of the Windows file system stack. I love projects that customize Windows (working against its closed-source nature).

There’s an OpenZFA port to Windows[0]. I wonder if my hopes of having ZFS on Windows (including the boot drive, because I would love to be able to snapshot and rollback) would actually be possible.

[0] https://github.com/openzfsonwindows/openzfs

*cough* it can, but... no idea how well it works but it seems a bit hacky.

If you have not used it, maybe the native ZFS port for windows could be an easier solution.

Theoretically ZFS is ported to windows, but I heard that it is not really stable yet.

I did use the packages provided here: https://github.com/openzfsonwindows/openzfs/releases/tag/zfswin-2.1.6rc2

Assuming the dump file provided is representative, have you gone through the steps in the Resolution and Remarks sections on this page? The sub error from the bugcheck is:

Edit: Apparently there is a new API that simplifies this process (docs)

I opened on issue on https://github.com/MicrosoftDocs/windows-driver-docs/issues/3289

This is pretty technical, but it can help point you at what's causing this issue. https://github.com/MicrosoftDocs/windows-driver-docs/blob/staging/windows-driver-docs-pr/debugger/bug-check-0xa0--internal-power-error.md

I thought ChangeDisplaySettingsEx and EnumDisplaySettings was superseded by SetDisplayConfig and QueryDisplayConfig, respectively? https://github.com/MicrosoftDocs/windows-driver-docs/blob/st... calls ChangeDisplaySettingsEx "legacy API".

From my experience, changing topology using SetDisplayConfig() is straightforward.

The biggest thing with digital signatures is that getting one trusted by Windows means entertaining a racket enabled by Microsoft.

There are two types of code signing certificates: regular, and EV. With regular certificates, all you get is effectively a way to carry your antivirus-based reputation with you as you continue to sign new binaries with it. At first sight, Windows will still throw up smartscreen warnings about it being potentially dangerous, until it's seen the certificate enough to trust it for new binaries.

With EV certificates, everything is smooth sailing - only if actual malware is reported does your certificate get slammed by antivirus reputation, otherwise you can sign anything and it'll instantly bypass all AV software and Windows smartscreen prompts.

The issue with getting either of these is that absolute cheapest one you can get is $59 a year for 3 years via a reseller[0] of Sectigo certificates, and that is only for regular code signing. If you want an EV certificate, it's going to be $219 a year for 3 years at the minimum via the same reseller (do not try to go through the regular channels or you'll likely be paying 2x-3x more[1]).

Thankfully Microsoft is aware of these concerns[2,3] and there is a potential solution coming up called Azure Code Signing[4] however no new public information has been released since that video went up.

0: https://codesigncert.com/brand (this is just the cheapest site I've found - I am not affiliated with them beyond being a customer)

1: https://sectigo.com/ssl-certificates-tls/code-signing

2: https://github.com/MicrosoftDocs/windows-driver-docs/issues/...

3: https://github.com/MicrosoftDocs/windows-driver-docs/issues/...

4: https://youtu.be/Wi-4WdpKm5E?t=530

Okay, apparently this error is very new, here someone's asking about it. Unfortunately it doesn't give any additional information.