Windows10Pro-64 System Freezing about btrfs HOT 33 CLOSED

Hi Jarrard,

Sorry to hear this. I think I'm going to put in a feature which allows you to create debug logs, which should help solve things like this. I've never encountered this in my own testing.

As for getting Windows bootable again, have you tried running btrfs check --repair? If it worked once but then stopped, it implies the driver corrupted the filesystem. Failing that, I'd make it so Windows can't find your btrfs partition - use a Linux boot disc, write down your partition's details in fdisk, delete it, then recreate it afterwards. Once you're in Windows, you can tell it not to load the btrfs service.

from btrfs.

deleting btrfs sys file in a linux boot disk fixed it

On 24 February 2016 at 06:44, maharmstone [email protected] wrote:

Hi Jarrard,

Sorry to hear this. I think I'm going to put in a feature which allows you
to create debug logs, which should help solve things like this. I've never
encountered this in my own testing.

As for getting Windows bootable again, have you tried running btrfs check
--repair? If it worked once but then stopped, it implies the driver
corrupted the filesystem. Failing that, I'd make it so Windows can't find
your btrfs partition - use a Linux boot disc, write down your partition's
details in fdisk, delete it, then recreate it afterwards. Once you're in
Windows, you can tell it not to load the btrfs service.

—
Reply to this email directly or view it on GitHub
#3 (comment).

I've noticed that when I strive to achieve and succeed, I distance myself
from the moment.

from btrfs.

There's always that!

from btrfs.

Could you please post the output of btrfs check? There might be something interesting in there. Thanks

from btrfs.

Sure thought I have since formatted the drive back to NTFS. Are you wanting
me to reinstall the service with loader.exe/reboot/ then try the check in
CMD prompt?

On 24 February 2016 at 08:19, maharmstone [email protected] wrote:

Could you please post the output of btrfs check? There might be something
interesting in there. Thanks

—
Reply to this email directly or view it on GitHub
#3 (comment).

I've noticed that when I strive to achieve and succeed, I distance myself
from the moment.

from btrfs.

Shame - never mind then.

from btrfs.

I can still test it with my Linux partitions which I have setup to use
BTRFS, it might result in me loosing the partition but I will give it a try
and see what btrfs says. Like I said before I can only do it via the Loader
method as installing the driver upfront results in a hard crash.

PS. Sorry I have been distracted last couple days.

On 26 February 2016 at 05:40, maharmstone [email protected] wrote:

Shame - never mind then.

—
Reply to this email directly or view it on GitHub
#3 (comment).

I've noticed that when I strive to achieve and succeed, I distance myself
from the moment.

from btrfs.

I will boot into Linux and to a btrfs check on the linux partitions to
ensure they are all ok (I assume that's where btrfs check --repair is used).
Then fiddle around with them again back in Windows. Let me know if you
managed to update the driver with some form of logging so if the system
starts stalling again I can at least give you that.

On 26 February 2016 at 06:45, Prime Technophilia <[email protected]

wrote:

I can still test it with my Linux partitions which I have setup to use
BTRFS, it might result in me loosing the partition but I will give it a try
and see what btrfs says. Like I said before I can only do it via the Loader
method as installing the driver upfront results in a hard crash.

PS. Sorry I have been distracted last couple days.

On 26 February 2016 at 05:40, maharmstone [email protected]
wrote:

Shame - never mind then.

—
Reply to this email directly or view it on GitHub
#3 (comment).

---

I've noticed that when I strive to achieve and succeed, I distance myself
from the moment.

I've noticed that when I strive to achieve and succeed, I distance myself
from the moment.

from btrfs.

Ok so what I will do is delegate 40gb of the original drive I was using for
testing this driver. I have ran btrfs check --repair on it and all is good
so will see how this goes. In all honesty if winbtrfs fails to mount a
drive or access a drive it shouldn't be stalling the system as a response,
perhaps you need to code in the driver to FORCE dismount of the problem
drive if a read-write failure occurs? This would be much better then the
system going into meltdown mode :)

On 26 February 2016 at 06:53, Prime Technophilia <[email protected]

wrote:

I will boot into Linux and to a btrfs check on the linux partitions to
ensure they are all ok (I assume that's where btrfs check --repair is
used). Then fiddle around with them again back in Windows. Let me know if
you managed to update the driver with some form of logging so if the system
starts stalling again I can at least give you that.

On 26 February 2016 at 06:45, Prime Technophilia <
[email protected]> wrote:

I can still test it with my Linux partitions which I have setup to use
BTRFS, it might result in me loosing the partition but I will give it a try
and see what btrfs says. Like I said before I can only do it via the Loader
method as installing the driver upfront results in a hard crash.

PS. Sorry I have been distracted last couple days.

On 26 February 2016 at 05:40, maharmstone [email protected]
wrote:

Shame - never mind then.

—
Reply to this email directly or view it on GitHub
#3 (comment).

---

I've noticed that when I strive to achieve and succeed, I distance myself
from the moment.

---

I've noticed that when I strive to achieve and succeed, I distance myself
from the moment.

I've noticed that when I strive to achieve and succeed, I distance myself
from the moment.

from btrfs.

Just did another test write to this btrfs test partition under windows and
the system stalled, this partition was checked for errors under Linux. So I
would say this driver is no good in its present condition, it is a shame
that it HALTS the system preventing any sort of logging but that is the way
it is.

On 26 February 2016 at 08:16, Prime Technophilia <[email protected]

wrote:

Ok so what I will do is delegate 40gb of the original drive I was using
for testing this driver. I have ran btrfs check --repair on it and all is
good so will see how this goes. In all honesty if winbtrfs fails to mount a
drive or access a drive it shouldn't be stalling the system as a response,
perhaps you need to code in the driver to FORCE dismount of the problem
drive if a read-write failure occurs? This would be much better then the
system going into meltdown mode :)

On 26 February 2016 at 06:53, Prime Technophilia <
[email protected]> wrote:

I will boot into Linux and to a btrfs check on the linux partitions to
ensure they are all ok (I assume that's where btrfs check --repair is
used). Then fiddle around with them again back in Windows. Let me know
if you managed to update the driver with some form of logging so if the
system starts stalling again I can at least give you that.

On 26 February 2016 at 06:45, Prime Technophilia <
[email protected]> wrote:

I can still test it with my Linux partitions which I have setup to use
BTRFS, it might result in me loosing the partition but I will give it a try
and see what btrfs says. Like I said before I can only do it via the Loader
method as installing the driver upfront results in a hard crash.

PS. Sorry I have been distracted last couple days.

On 26 February 2016 at 05:40, maharmstone [email protected]
wrote:

Shame - never mind then.

—
Reply to this email directly or view it on GitHub
#3 (comment).

---

I've noticed that when I strive to achieve and succeed, I distance
myself from the moment.

---

I've noticed that when I strive to achieve and succeed, I distance myself
from the moment.

---

I've noticed that when I strive to achieve and succeed, I distance myself
from the moment.

I've noticed that when I strive to achieve and succeed, I distance myself
from the moment.

from btrfs.

Hi,
I've just released a new version which contains a ton of bugfixes, could you try that please?
Thanks

from btrfs.

Ok will do.

On 14 March 2016 at 07:53, maharmstone [email protected] wrote:

Hi,
I've just released a new version which contains a ton of bugfixes, could
you try that please?
Thanks

—
Reply to this email directly or view it on GitHub
#3 (comment).

I've noticed that when I strive to achieve and succeed, I distance myself
from the moment.

from btrfs.

Using the loader.exe method:

UPDATE: Sadly I got a system wide crash after trying to copy 500mb to my btrtest drive which I tested in Linux as being ok. This time the crash just restarted my computer instead of freezing it with the sound going funny.

Not sure if any log files are created, can't see anything extra in the BTR directory.

from btrfs.

Shame. By default, the log file is created at C:\btrfs.log - you'll need to have set DebugLogLevel in the registry to get anything at all, though.

Could you please try and reproduce the error, and send me a minidump? There's instructions at https://support.microsoft.com/en-us/kb/315263 about how to get Windows to generate one. I'd love to know what's causing this...

from btrfs.

Ok I have enabled the debug driver and registry, and will also produce a core dump when I try it out.

I was only able to get the log file below, the system fails to produce any minidump. Must be a real nasty crash that kills the system good.

When I was using BTRtest I did notice it went slow and attempted to restart it a few times (might show in log), maybe its because I had debug drivers and not normal so some delay is expected? non the less it failed when I did finally start coping files over. Probably managed to get to 1000mb this time before system fell over.

btrfs.zip

from btrfs.

I'm not familiar with system event logs but apparently there may be something in that? It says Critical - Kernel Power, sadly when I go to view the event log online it just takes me to MS Store and tries to sell me crap, typical.

EDIT: https://support.microsoft.com/en-us/kb/2028504 well this is what your driver does to my system it seems?

from btrfs.

Thank you, I think we're getting somewhere. The crash is something the driver has done deliberately, because it was about to corrupt your filesystem - that's why Windows doesn't know what's going on.

I think I see what the problem is. When it comes to flushing the metadata, the driver allocates addresses to any tree with an address of 0, meaning it doesn't have one already. Normally 0 isn't a valid address because the very first chunk is marked SINGLE, and metadata is normally DUP. The Linux driver marks metadata on SSDs as SINGLE by default, meaning that 0 would be a valid address, hence the confusion.

Give me a day or two and I'll try and fix it. Thanks for your patience.

from btrfs.

Thanks, I look forward to and update.

from btrfs.

I've just released a new version which ought to fix your issue.

from btrfs.

Ok will give it a go.

from btrfs.

Ok seems it works without crashing now, just couple small issues I noticed.

1. the copy process will goto 0mb/sec every 5-10seconds for about 4sec (seems to halt copying briefly)
2. For some reason the copy process was unable transfer certain exe/cmd files from my storage drive, odd behavior as these files copied fine to other locations. Windows claims it could not find the source file??! Again this doesn't occur for all executable files just certain ones, I really can't figure out whats different about them to be honest...

from btrfs.

for example I can't copy bid_4_77_setup.exe from my storage drive to the btrfs drive as it claims it can't find it, however other exe files from that same folder copied fine. I wondered if there was some issue with the files details description that was causing it but couldn't really spot anything.

Not sure if uploading these exe files that cause the issue will help you at your end as may be specific problem with my Windows10 system?

from btrfs.

The metadata gets flushed to disk every 15 seconds, which will temporarily halt any other I/O - I'm guessing that's what causing the problem there. It should only take a few milliseconds though, not four seconds.

Please do upload your EXE file, it can't hurt. I'm not sure it's a problem with the driver though, if Windows is complaining about the source rather than the destination. Sounds to me like a FS filter driver in play, such as from an antivirus.

from btrfs.

I only have Defender enabled, and it has no reports of any file issues.

Here's a file that causes the issue, just some random application of sorts.

bid_4_77_setup.zip

from btrfs.

Alternatively I can also give you TeamViewer access to my system to see with your own eyes the issues I mention. I would be sitting at the system at the same time so its not like any privacy issues could occur (this PC is just full of random crap anyway).

This would give you the ability to understand the issue(s) a little better then trying to replicate them at your end (which seems to be difficult for you to do? Not using Win10 perhaps?)

from btrfs.

Thanks for the offer, but I'd really need access to the kernel debugger, and that's not something you can easily do over the Internet.

I can't replicate your issue - your file copies fine for me. Could you please send me a log file of it failing?

from btrfs.

Here is a log file, it took quite some time for it to STOP logging and unload the service/driver. So really not sure if the error would be at the end or not.

Perhaps it doesn't unload the driver fully when on debug mode. Anyway making a copy of the log resolves the "being used issue".

btrfs - Copy.zip

from btrfs.

How did you go with testing this? Should I create a new issue for this weird file copy problem?

It seems pretty consistent, I can enable the btrfs anytime and those same files fail to copy, yet copy fine to NTFS HDD. Must be something amiss!

If your got a CD/DVD of old files and programs, zips and stuff like I do (collecting apps and drivers over the years) then that is best source of testing, doing a raw copy of say ISO/AVI or collection of RAR/ZIP files doesn't appear to cause a problem.

from btrfs.

I've not been able to reproduce this myself. The log file says that the file is being created and written to, Windows tries and fails to read the data stream "Zone.Identifier", and then it decides to delete the whole thing.

Could you try something for me please? Copy one of the offending files to a FAT volume, like a thumb drive, then copy it from there to the Btrfs partition. If it works, we'll know the problem's due to something introduced with NTFS.

from btrfs.

Yep you were right, I copied it to a Fat32 usb pen THEN copied it successfully to the BTRFS drive, no error. Weird!

I do hope this can be figured out, be a real bummer to haft to copy random files here and there to a fat32 drive before going to the btrfs volume.

from btrfs.

Now that I know what I'm looking for, I can reproduce it - copying files does indeed fail when they have an alternate data stream. I'll get it fixed for the next release.

from btrfs.

I've just released a new version which fixes this.

from btrfs.

Cheers for that. Can't wait for that async read/write feature :)

from btrfs.