Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible regression on the failure to create autorun.inf notice #1496

Closed
pbatard opened this issue Apr 1, 2020 · 2 comments
Closed

Possible regression on the failure to create autorun.inf notice #1496

pbatard opened this issue Apr 1, 2020 · 2 comments
Assignees
Milestone

Comments

@pbatard
Copy link
Owner

pbatard commented Apr 1, 2020

A user reported the following:

I think that the latest Rufus (Rufus x86 v3.9.1624) may have an issue,
or at least not deal as gracefully with an error as previous versions,
which stops it working.

On our PCs creation of an “autorun.inf” file is blocked entirely.

The relevant parts from the log seems to be below:

From 3.8:

Extracting files...
Image is an ISO9660 image
This image will be extracted using Rock Ridge extensions (if present)
Extracting: D:\autorun.inf (146 bytes)
Unable to create file: [0x00000005] Access is denied.
   NOTE: This is usually caused by a poorly designed security solution. 
See https://goo.gl/QTobxX.
   This file will be skipped for now, but you should really look into 
using a *SMARTER* antivirus solution.
Extracting: D:\boot\grub\efi.img (304 KB)
Extracting: D:\boot\grub\font.pf2 (4.9 KB)
Extracting: D:\boot\grub\grub.cfg (2.3 KB)
...

Whereas from 3.9:

Extracting files...
Image is an ISO9660 image
This image will be extracted using Rock Ridge extensions (if present)
Extracting: D:\autorun.inf (146 bytes)
Warning: Could not read file pointer [0x00000006] The handle is invalid.
Write error [0x00000006] The handle is invalid.
   Error writing file: [0x00000006] The handle is invalid.

I’m aware that this problem is caused by our IT dept. antivirus
solution, but there is no changing that, and (apart from the autorun.inf
file!) it all worked on previous versions.

I’m assuming something changed in the way 3.9 writes the files – is it
possible it could recover in the same way that 3.8 did, or are we stuck
with 3.8 forever more?

@pbatard pbatard added this to the 3.10 milestone Apr 1, 2020
@pbatard pbatard self-assigned this Apr 1, 2020
@pbatard
Copy link
Owner Author

pbatard commented Apr 1, 2020

I believe this was introduced in 4c5adf0 since we are no longer receiving an error code from CreateFile[U]() but from NtCreateFile(), which returns an NtStatus that is then converted to a conventional Windows error code.

Most likely, the ERROR_ACCESS_DENIED code we were getting previously has shifted to an ERROR_INVALID_HANDLE code.

@pbatard pbatard closed this as completed in b19f47f Apr 1, 2020
dyeske pushed a commit to dyeske/rufus that referenced this issue Jul 3, 2020
* Commit 4c5adf0 moved us away from using CreateFile()
  when extracting a file on the target media, and as such the error code returned when
  failing to create an 'autorun.inf' due to a security solution has shifted.
* Make sure we handle the new error and don't bail out on 'autorun.inf' creation.
* Also update the actual name of the RtlDosPathNameToNtPathNameXXX function we use.
* Closes pbatard#1496
@github-actions
Copy link

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 29, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant