Error 0x800704b3 when attempting to start executable from drive

[js69]

Tested with mirror.exe: when I attempt to start most executables from the virtual drive I get an error 0x800704b3 "The network path was either typed incorrectly, does not exist, or the network provider is not currently available."

Can I assume this is related to #47 as well?

[Liryna]

Do you have an example of executables that create such behaviour that I can test ?

[js69]

It's a result for most exes. You can test it with e.g. http://www.irfanview.info/files/iview441g_x64_setup.exe

[Maxhy]

Not sure if it is related but you can give a try by yourself using mountmanager branch if you want. The branch is quite stable now, only network drives are not working and need to be fixed.

[js69]

Same issue with the mountmanager-Branch, as far as I can tell (the dokan_install would not build in that branch so I used my WiX setup project. Only difference is removal of mounter.exe service?).

[Liryna]

Can you reclone the repository and retry the branch. An old branch with the same name was existing some days ago. (you probably link to the old branch)
I just tested and the installer work.

[js69]

Sorry, my mistake, my system had NSIS 2.46, not NSIS3 in the expected folder. Installer builds correctly with NSIS3.

[Liryna]

Ok !
Just pull the branch, I commit a BSOD fix some minutes ago :D

[Liryna]

@js69 I have reproced your issue. I made it work by launching it from a cmd.exe with admin rights.

[js69]

I can confirm it works from a Admin cmd.exe but It also gives the same error when attempting to "Run as administrator" from Explorer.

[Liryna]

Yes, I can just say that it is not a dokan issue but more a behaviour in the mirror.exe that is wrongly handled for this case since by command line with admin rights it work. (Explorer run as current user)

[js69]

DokanNet GetFileSecurityProxy returns DokanResult.BufferOverflow without admin rights, with admin rights that does not happen.

[Liryna]

@js69, The BufferOverflow is normal and also happen in the mirror.exe.
The system call GetFileSecurity with a buffer of length 0. It is offen made by the system to get the buffer LengthNeeded. (You can see that he call after with a buffer size correct)

Otherwise I do not know what is happening. I see that the security informations requested are different from the admin to the user.
BUT If you set GetFileSecurity to return STATUS_NOT_IMPLEMENTED, the same behaviour happen. Admin OK - User Error.

Therefore I would say that GetFileSecurity is working but it is another call that the system dont like.

I have not really the time to look on it with the mountmanager branch that need to be finished, if someone could look at this it would be great !

[marinkobabic]

Your issue seems to be related to UAC. https://www.osronline.com/showthread.cfm?link=168276

If you create a simple executable which does not require UAC prompt and create the same executable with a minifest file which requests the UAC prompt and test it. The one with UAC prompt will fail. Please can you confirm this behavior?

[js69]

From what I tested with a few executables that seems indeed to be a factor. If the exe does not require admin rights by itself, it will start.

Supplying a manifest file with "requireAdministrator" does not change anything for non-admin exes, neither does supplying a manifest file with "asInvoker" change a thing for admin exes.

Turning UAC off (i.e. to the lowest level) does not change anything either.

[marinkobabic]

Please can you test the following workaround:
https://technet.microsoft.com/en-us/library/ee844140(v=ws.10).aspx
This is related to network drives but maybe it helps. The device is created in the Global space, so it should not have any impact.

Did the stuff work before the change of Mount Manager? I mean the version with mount service.

[marinkobabic]

I think it's the Zone.Identifier which is causing some problems in Dokan. Type the following

notepad C:\Users\xx\Downloads\iview441g_setup.exe:Zone.Identifier

and you will get an output like the following one

[ZoneTransfer]
ZoneId=3

Please try then the following:

https://technet.microsoft.com/de-de/sysinternals/streams
Streams –d –s c:\tempdir

and then copy the exe file to dokan drive and let me know if it then works

[Liryna]

Hi @marinkobabic ,

I tested https://technet.microsoft.com/en-us/library/ee844140(v=ws.10).aspx and got the same behaviour.

notepad iview441g_x64_setup.exe:Zone.Identifier
Give me:

[ZoneTransfer]
AppZoneId=4

>Streams -d -s .

Streams v1.56 - Enumerate alternate NTFS data streams
Copyright (C) 1999-2007 Mark Russinovich
Sysinternals - www.sysinternals.com

C:\Users\liryna\Desktop\iview441g_x64_setup.exe:
   Deleted :Zone.Identifier:$DATA

>dir /R iview441g_x64_setup.exe
 Volume in drive M is DOKAN
 Volume Serial Number is 1983-1116

 Directory of M:\liryna\Desktop

01/09/2016  10:56 PM         3,617,120 iview441g_x64_setup.exe
               1 File(s)      3,617,120 bytes
               0 Dir(s)     536,870,912 bytes free

I tried to start it but unfortunately the behaviour is the same 😢

[marinkobabic]

if MirrorGetVolumeInformation looks the following way, then the stuff should work properly

static NTSTATUS DOKAN_CALLBACK MirrorGetVolumeInformation(
    LPWSTR VolumeNameBuffer, DWORD VolumeNameSize, LPDWORD VolumeSerialNumber,
    LPDWORD MaximumComponentLength, LPDWORD FileSystemFlags,
    LPWSTR FileSystemNameBuffer, DWORD FileSystemNameSize,
    PDOKAN_FILE_INFO DokanFileInfo) {
  UNREFERENCED_PARAMETER(DokanFileInfo);

  wcscpy_s(VolumeNameBuffer, VolumeNameSize, L"DOKAN");
  *VolumeSerialNumber = 0x19831116;
  *MaximumComponentLength = 256;
  *FileSystemFlags = FILE_CASE_SENSITIVE_SEARCH | FILE_CASE_PRESERVED_NAMES |
                     FILE_SUPPORTS_REMOTE_STORAGE | FILE_UNICODE_ON_DISK |
                     FILE_PERSISTENT_ACLS;

  wcscpy_s(FileSystemNameBuffer, FileSystemNameSize, L"FAT");
  DbgPrint(L"  returning file system name: FAT\n");

  return STATUS_SUCCESS;
}

This is what RamDisk example from Microsoft does. There are many other filesystems and those work properly so the workaround above can't be the solution.

[Liryna]

Oh @marinkobabic 😗 !!!
It work perfectly 😄 Funny that is it so 'simple'.

Should we rename the FileSystemNameBuffer to FAT in the mirror by default ?
And also in dokan.dll

dokany/dokan/volume.c

Line 51 in 1534370

wcscpy_s(FileSystemNameBuffer, FileSystemNameSize, L"Dokan");

[marinkobabic]

We need to go on with investigations and solve the issue in a proper way. There are many other filesystems and those work also properly on Windows. So dokan will work as well, but it takes some time to figure out what is the source of the problem.

[js69]

I can confirm it works with DokanNet as well when I set fileSystemName = "FAT". It also works with "NTFS".

[Maxhy]

Indeed after further investigation this is kind of normal (Windows point of view 💀). Any file system name can be set here, but since Windows Vista (since UAC strangely...) it seems that Windows doesn't start elevated processes from file systems other than NTFS and FAT, and from what I read but not tested FAT32, CDFS, NPFS, MSFS or UDF would be fine too. Probably for security reasons at start and the implementation was simplified by Microsoft engineers.
I will update the documentation and mirror sample.
Thanks for the investigation @js69 @Liryna, and thanks a lot for the issue identification @marinkobabic.

EDIT with sources:
https://www.osronline.com/showthread.cfm?link=168276
http://www.osronline.com/showthread.cfm?link=166472
http://www.osronline.com/showThread.cfm?link=129811
http://www.osronline.com/showThread.cfm?link=121274