Initial install fails with 0x8007001f

[DrPizza]

Performing the initial install of the bare Ubuntu system fails.

C:\>bash
-- Beta feature --
This will install Ubuntu on Windows, distributed by Canonical
and licensed under its terms available here:
https://aka.ms/uowterms

Type "y" to continue: y
Downloading from the Windows Store... 100%
Extracting filesystem, this will take a few minutes...
Please create a default UNIX user account. The username does not need to match your Windows username.
For more information visit: https://aka.ms/wslusers
Enter new UNIX username: DrPizza
Creating UNIX user failed, this can be done later by running lxrun.exe /setdefaultuser
Installation successful!
The environment will start momentarily...
Documentation is available at:  https://aka.ms/wsldocs
Error: 0x8007001f

I'm on 14393.5

I turned on the Linux subsystem (the PC was already in developer mode), rebooted, and ran bash at an Administrator command prompt.

[aseering]

Just out of curiosity, does it work if you run bash at a regular (non-administrator) prompt? I've never tried it at an administrator prompt.

[DrPizza]

Same error as non-Admin.

[benhillis]

Something strange is happening. Would you be able to collect a trace during install so I can take a look at what's happening? 0x8007001f translates into "A device attached to the system is not functioning" and I'm not sure where that could be coming from.

Thanks!

1. Download the below two .txt files and rename them .cmd
2. Run start_lxcore_trace.cmd from an admin command prompt
3. Start the install.
4. Wait until you see the error.
5. Run stop_lxcore_trace.cmd from an admin command prompt
6. You should now see three .etl files in the directory you ran the script from.
7. Email the logs to: [email protected]. Include in the subject / message to forward to the WSL team. In the body of the email mention it is for russalex and benhill.

https://github.com/Microsoft/BashOnWindows/files/288621/start_lxcore_trace.txt
https://github.com/Microsoft/BashOnWindows/files/288622/stop_lxcore_trace.txt

[DrPizza]

YGM. Or if you don't want to wait for the mail, the files are available
here

[benhillis]

Thanks. Took a quick look at the trace and saw that our driver is failing to set up the root mount point. By chance have you done anything interesting with your %localappdata% folder?

[DrPizza]

Not knowingly, no. What is it trying to do that's failing?

[benhillis]

Trying to open a handle to the %localappdata%\lxss\rootfs directory and failing with file not found. I'll have a chat with the owner of this code path and see if we can figure out what's happening here.

If you navigate to %localappdata%\lxss in Windows Explorer can you see this folder? (copy and paste the path into explorer because the lxss directory is marked as hidden and system)

[DrPizza]

Hmm, that's strange. This looks superficially OK to me:

C:\Users\DrPizza\AppData\Local\lxss>cacls %localappdata%\lxss\rootfs
C:\Users\DrPizza\AppData\Local\lxss\rootfs NT AUTHORITY\SYSTEM:(OI)(CI)F
                                           BUILTIN\Administrators:(OI)(CI)F
                                           MEXICANUS\DrPizza:(OI)(CI)F

[benhillis]

@DrPizza That matches what is shown on my machine locally. Do you have a virus scanner or some other piece of windows software that would include a filter driver? It's very odd that our driver cannot find the rootfs folder but your user can.

[DrPizza]

Weird I thought I replied by e-mail but it's not showing.

The only AV I'm using is Windows Defender.

A process monitor trace seems to show handles successfully being opened to that folder.

[TSlivede]

I get the same error, but only if I disable caseinsensitivity in windows by setting
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\ dword:ObCaseInsensitive to 0
(see https://technet.microsoft.com/en-us/library/cc725747.aspx)
(I use this setting this for cygwin, see https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive)

This Problem was also mentioned here: https://github.com/Microsoft/BashOnWindows/issues/101
But that issue is closed now, because /mnt/* is now case sensitiv by default.

If I set ObCaseInsensitive to 1:
=> Ubuntu on Windows works fine, but cygwin isn't casesensitiv any more.

[DrPizza]

Hmmm. This system was upgraded from one that used SUA (rest in peace), and hence had case insensitivity disabled. Let me flip the flag and reboot, see if it makes any difference.

[DrPizza]

OK, flipping that flag did indeed fix this error code, and bash now installs.

I've had that flag enabled for literally years, and I've even had WSL run successfully on this system in the past in earlier builds. Why it should cause a problem now is very strange.

[btecu]

I have a similar problem, except mine always crashes when trying to create the user and therefore I can't run bash either.
I've tried setting ObCaseInsensitive to 1 but it doesn't make a difference.

C:\Users\myUser>lxrun.exe /setdefaultuser
Please create a default UNIX user account. The username does not need to match your Windows username.
For more information visit: https://aka.ms/wslusers
Enter new UNIX username: myuser
Error: 0x8007001f

[BeErikk]

I can confirm @btecu errors

Administrator console:

Type "y" to continue: y
Downloading from the Windows Store... 100%
Extracting filesystem, this will take a few minutes...
Please create a default UNIX user account. The username does not need to match your Windows username.
For more information visit: https://aka.ms/wslusers
Enter new UNIX username: sockerconny
Creating UNIX user failed, this can be done later by running lxrun.exe /setdefaultuser
Installation successful!
The environment will start momentarily...
Documentation is available at:  https://aka.ms/wsldocs
Error: 0x8007001f

C:\Windows\system32>lxrun.exe /setdefaultuser
Please create a default UNIX user account. The username does not need to match your Windows username.
For more information visit: https://aka.ms/wslusers
Enter new UNIX username: sockerconny
Error: 0x8007001f

C:\Windows\system32>bash
Error: 0x8007001f

Fresh clean install of 1607, practically no application installs
Active Directory machine and Hyper V though

[ajthemacboy]

I get this error after I installed the Anniversary Update (I had bash previously installed and working fine.)

obcaseinsensitive is set to 1 by default.

Edit: I'll note that I changed my AppData directories to my second HD using hard symlinks, as @benhillis inquired before.

[btecu]

@jerker-back Interesting, my computer is also part of an Active Directory so that might be the problem.
Does %localappdata%\lxss exist in your case? Doesn't exist on my computer and unlike @ajthemacboy I have not moved or changed the location of my profile folder.
Perhaps @benhillis can give us some ideas.

[ajthemacboy]

%localappdata%\lxss does not exist for me. After my previous report I;

• Reinstalled Windows to test whether various broken functions worked without symlinks (Start menu and LXSS were both broken after I symlinked %AppData%)
• LXSS and Start Menu worked fine on a fresh install, and broke after symlinking %AppData% again
• Reinstalled again and haven't symlinked %AppData% since, LXSS and Start menu continue to work fine

[benhillis]

Moving your AppData directory and using symlinks could definitely cause issues. I can't think of anything that Active Directory would do to make install not work.

[DrPizza]

How glorious.

My previously working WSL has now stopped working with, guess what, error 0x8007001f.

And so I look in the registry and... something has flipped obcaseinsensitive to 0. What changed it? Who knows!

On the one hand, I wish I could figure out why the object manager keeps being reverted to the case sensitive mode. I think the default was switched around XP time, and since I don't need any other behaviour it's probably better to stick with the default.

On the other hand, I figure that at least for the short term people are gonna want to mix and match Cygwin and WSL, and having Cygwin be case-sensitive probably helps this. It seems really kind of weird that a Linux-like subsystem, of all things, should throw a fit when the Object Manager is doing case sensitive lookups!

[BeErikk]

@btecu yes everything in the installation was successful in my case. My default casesensitive registry key was/is:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\obcaseinsensitive = 0

Initially I got the 0x8007001f error unless I changed obcaseinsensitive to 1. This setting will however revert back to 0 sooner or later automagically. I had to change it back a couple of times. :D

Now the subsystem suddenly works for me even with obcaseinsensitive = 0

Did they update it somehow? I can't see any updates though.

So I can basically confirm @DrPizza's experiences as well

[DrPizza]

Aaaaand it's flipped to 0 again.

[benhillis]

@DrPizza That sounds frustrating, I'm not sure what component might be resetting that reg key flag.

When you first reported this issue I tried to reproduce this locally with the obcaseinsensitive flag set to 0 and wasn't able to. I suspect there's something different with your machine environment than mine.

Out of curiosity if you do an "echo %localappdata%" and compare the case of the path with the actual on-disk path elements do all of the character cases match?

[DrPizza]

C:\Users\DrPizza\AppData\Local>echo %localappdata%
C:\Users\DrPizza\AppData\Local

Looks the same to me. I'm currently running procmon to see if I can figure out at least what's flipping the value.

[sundhaug92]

The reg-key wouldn't happen to be reset when a new build is installed?

[DrPizza]

Not sure, but this system is on the stable ring, so should only be updated with the monthly cumulative fixes.

[DrPizza]

Caught in the act, I think?

I'll still keep monitoring to see if anything else is messing with the registry key. I wonder if maybe a GPO is doing it?

[DrPizza]

Oh well, would you look at that.

Changing the policy and running gpupdate confirms it; this is what's messing with the key.

Probably a relic of the SUA/Interix days, where I wanted to ensure that case sensitivity was allowed. I'm guessing that the value will stop getting changed now.

Now, I still feel that it should be working regardless of the value, especially as @benhillis says that it was working for him regardless (presuming he rebooted between each trial? The value only gets read at system start). It seems a little peculiar that enabling case-sensitive subsystems should break a case-sensitive subsystem.

[BeErikk]

@DrPizza Yes my group policy also disabled the setting, explained here
https://technet.microsoft.com/en-us/library/jj852277(v=ws.11).aspx
My group policy has been on since the SUA days and as you said the setting is probably due to advise at the Interix site. I have a vague memory of the event.
My Linux subsystem is working fine though with all these settings.

[eryksun]

Some programs bypass the Windows API, via the NT API or device drivers, and fail to set OBJ_CASE_INSENSITIVE in a system call's OBJECT_ATTRIBUTES. From what I can tell, rather than fix this code, XP (NT 5.1) added the ObCaseInsensitive registry setting, which is enabled by default. Is that the rationale? If not, I wish someone on the kernel team would write an article explaining the rationale for this change. It breaks FILE_FLAG_POSIX_SEMANTICS (CreateFile), FIND_FIRST_EX_CASE_SENSITIVE (FindFirstFileEx), and the older POSIX subsystem (and Cygwin). It was never even documented that the default configuration in XP and later breaks these WinAPI flags.

Please, try to fix your code to work when the ObCaseInsensitive setting is disabled. Drivers and NT API programs that need case-insensitive access should specify OBJ_CASE_INSENSITIVE when opening objects by name. Anything else is a bug.

I disabled the protection on the svchost.exe process to attach a debugger and track the problem to an NtDeviceIoControlFile syscall directed at \Device\lxss with I/O control code 0x00220073 (function 28). The call has the following stack trace:

ntdll!NtDeviceIoControlFile
lxssmanager!AdssBusClientpIoctl
lxssmanager!LxssInstance::_StartInstance
lxssmanager!LxssInstance::StartSelf
lxssmanager!LxssSession::RunningInstanceContext::Replace
lxssmanager!LxssSession::_ActivateInstance
lxssmanager!LxssSession::StartDefaultInstance
...

It fails with the generic status code STATUS_UNSUCCESSFUL (0xC0000001), which maps to the HRESULT code 0x8007001F, i.e. the Windows error (0x8007) ERROR_GEN_FAILURE (0x001F).

[jiamo]

same error:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel]
"obcaseinsensitive"=dword:00000000

install the reg, bash met the same error. I do this becuase I want cygwin's fstab posix = 1

# This is default anyway:
none /cygdrive cygdrive binary,noacl,posix=1,user 0 0 

[jiamo]

build 14931 fix it.

[nailk]

I'm running 14393.351 and still cannot start bash because of this error.

[btecu]

@nailk 14393 < 14931.

[bdennir]

hmm... ditto

[phisad]

I had the same Error: 0x8007001f

This might be, because I change the registry entry for case-sensitivity to 0. When changing it back to 1, the prompt starts now (after reboot and reinstallation).

Looks like it couldn't install the lxss folder.

[benhillis]

The legacy install mechanism (lxrun.exe) is deprecated.