Jump to content











Photo
- - - - -

GetFinalPathNameByHandle fails with ERROR_INVALID_FUNCTION

bug

  • Please log in to reply
9 replies to this topic

#1 Cherry

Cherry
  • Members
  • 4 posts
  •  
    Austria

Posted 25 April 2019 - 10:21 AM

Hi,

 

it appears that calling GetFinalPathNameByHandle on files on a RAM disk fails with ERROR_INVALID_FUNCTION, which seems to be translated from an NTSTATUS of STATUS_INVALID_DEVICE_REQUEST.

 

This causes trouble with some MSI installers. For example, Evernote updates won't run because my Temp directory is on a RAM disk, and the installer calls GetFinalPathNameByHandle and this ends up as an error box "The system cannot open the device or file specified." for some reason. The log shows "Error: Getting file path failed: R:\Temp\Evernote.msi, error = 1".

 

This seems to affect others as well, see for example https://developercom...ckageac-14.html or https://forums.virtu...php?f=6&t=92826. Of course I can't tell what RAM disk software those people are using, but it's likely that it's the same issue.

 

I wrote a FreeBASIC program that can reproduce this problem:

 

#Define _WIN32_WINNT &h0602
#Include "windows.bi"

Sub Test(filename As String)
  Var hFile = CreateFile(filename, GENERIC_READ, FILE_SHARE_READ Or FILE_SHARE_WRITE Or FILE_SHARE_DELETE, NULL, OPEN_EXISTING, NULL, NULL)
  Dim s As ZString * MAX_PATH
  Var res = GetFinalPathNameByHandle(hFile, @s, SizeOf(s) - 1, FILE_NAME_OPENED)
  Var lastError = GetLastError()
  CloseHandle(hFile)

  Print filename, res, lastError, s
End Sub

Test("c:\windows\explorer.exe")
Test("r:\temp\update.dat")

Sleep

/'

RESULT:

c:\windows\explorer.exe     27            0             \\?\C:\Windows\explorer.exe
r:\temp\update.dat          0             1

'/

As you can see here, calling GetFinalPathNameByHandle on a file on C:\ works as expected, while calling it on a file on R:\ (my RAM disk) returns error 1.

 

I'd be happy if this could be addressed.

 

Thanks!

Cherry

 

EDIT: I installed the RAM disk several months ago, and I wasn't able to figure out which version it is (because I get all kinds of version numbers from the EXE files, e.g. config.exe is 3.3.1.0, RAMDiskUI.exe is 7.3.3.0, ...), but I see that there was an update in November, so it's possible I don't have the latest version. However I cannot reboot my computer right now so I cannot say if an update will fix it - in case this is already known and fixed, please excuse my useless post then.


Edited by Cherry, 25 April 2019 - 10:23 AM.


#2 v77

v77

    Silver Member

  • Team Reboot
  • 602 posts
  •  
    France

Posted 25 April 2019 - 10:43 AM

EDIT: I installed the RAM disk several months ago, and I wasn't able to figure out which version it is (because I get all kinds of version numbers from the EXE files, e.g. config.exe is 3.3.1.0, RAMDiskUI.exe is 7.3.3.0, ...), but I see that there was an update in November, so it's possible I don't have the latest version. However I cannot reboot my computer right now so I cannot say if an update will fix it - in case this is already known and fixed, please excuse my useless post then.


All these version numbers are just for monitoring changes of each file separately.
The main number version of the Toolkit is given by the file properties of the installer, or by checking the General Settings in the Start menu.

For the rest, it's a driver issue so I leave it to Olof.

#3 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 25 April 2019 - 12:08 PM

The issue is "inherent" to the nature of IMDISK (that bypasses the Volume Mount Manager)
Olof already commented on it:
http://reboot.pro/to...lity-in-imdisk/

Try with Arsenal Image Mounter, it should work fine, as it is a "real" virtual disk driver.

:duff:
Wonko
  • Olof Lagerkvist likes this

#4 Cherry

Cherry
  • Members
  • 4 posts
  •  
    Austria

Posted 25 April 2019 - 12:13 PM

Ah I see. Seems my mistake was that I searched for "GetFinalPathNameByHandleW ImDisk" (with the W...) and didn't find this other thread.

 

I will try and find out how I can replace my ImDisk RAM Disk with Arsenal Image Mounter :) Thank you very much.


  • Olof Lagerkvist likes this

#5 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 25 April 2019 - 12:27 PM

Ah I see. Seems my mistake was that I searched for "GetFinalPathNameByHandleW ImDisk" (with the W...) and didn't find this other thread.
 
I will try and find out how I can replace my ImDisk RAM Disk with Arsenal Image Mounter :) Thank you very much.

You are welcome. :)

Most probably a lot of users would appreciate a tool for AIM corresponding to the Imdisk Toolkit by v77 (hint. hint ;)), but if you use command line the "transition" should be relatively easy, Olof has tried his best to keep commands the same or similar.

Please understand how what is in this case an issue for Imdisk. could be considered a "feature" as well, with AIM you will find that the disk is an actual \\.\PhysicalDrive besides only the volume (BTW additionally invisible to mountvol) as with Imdisk and this may cause changes in Physical Drives enumeration, or however changes in the environment that Imdisk simply does not cause.

:duff:
Wonko
  • Olof Lagerkvist likes this

#6 Cherry

Cherry
  • Members
  • 4 posts
  •  
    Austria

Posted 03 May 2019 - 03:45 PM

Hello again,

 

I'm struggling to switch to the image mounter. The RAM disk configurator in ImDisk ensures that the RAM disk exists always, so from starting Windows on there is always the temp directory available.

 

But how can I do the same with AIM? I never specified anything in the command-line, I used the RAM disk configurator.

 

(Also, I started seeing more and more issues with GetFinalPathNameByHandle and MSI in the last few weeks, is there a Windows update causing this? It also happens on my virtual drive that I use for ages via a custom DosDevices symlink :( )



#7 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 May 2019 - 11:52 AM

Well, you are using the IMDISK TOOLKIT (which is NOT IMDISK).

 

Some (most but not all) of the features of the IMDISK TOOLKIT can be replicated by IMDISK command lines (as an example by auto-executing a batch at startup time), but you'll have to "dirty your hands" a bit researching and testing these command lines, and then the same (or very similar) commands can be ported to AIM.

 

Namely, in this case see:

http://reboot.pro/to...der-on-startup/

 

 

:duff:

Wonko



#8 Cherry

Cherry
  • Members
  • 4 posts
  •  
    Austria

Posted 06 May 2019 - 05:28 PM

Thanks - the link to the actual guide is down but according to the comments, all that's needed is to call the imdisk (now AIM) cli in a scheduled task... To be honest I thought there is something more fancy involved because the ImDisk Toolkit seems to use a custom system service for it and I was afraid I would run in strange issues if the temp directory is not there when it's needed.

 

I'll then just play with a normal scheduled task ;) Thank you.


Edited by Cherry, 06 May 2019 - 05:28 PM.


#9 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 13 May 2019 - 06:54 AM

Thanks - the link to the actual guide is down ...

 

Yep :), for some strange reasons the board software developers (i.e. not only the software we have here on reboot.pro) have a "quirk" for changing the way pages are addressed (and resolved) on the boards :frusty: so that linked contents (while still there) cannot be found easily.

 

Most probably the board of the dressrview was updated and the way threads are addressed changed, specifically, you need to transform:

http://thessdreview....ftware/1834.htm

into:

http://www.thessdrev...hreads/1834.htm

that resolves to:

http://www.thessdrev...a-ramdisk.1834/

 

I guess that the issue with a "plain" autoexecuting or scheduled batch (as opposed to a dedicated service) is with timing, in the sense that while the dedicated service always works on all machines with all configurations, the alternative may need some "tuning" or "tweaking" to work reliably on a given PC/machine.

 

:duff:

Wonko



#10 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 13 May 2019 - 06:56 AM

Cross-linking to the already given thread:
http://reboot.pro/to...der-on-startup/

:duff:
Wonko





Also tagged with one or more of these keywords: bug

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users