逆向Windows可执行文件时CreateFile打开存在文件失败（错误码-1）求助

Let's break down the common reasons why your CreateFile call is failing even though the file exists in the same directory, and how to diagnose them:

Key First Step: Get the Exact Error Code #

The return value of -1 (aka INVALID_HANDLE_VALUE) only tells you the call failed—not why. Immediately after the failed CreateFile call, run GetLastError() (in your debugger, use a command like !gle in x64dbg or check the error register) to get a specific code. Common culprits here include:

• ERROR_FILE_NOT_FOUND: The file isn't where the program expects it to be
• ERROR_ACCESS_DENIED: You don't have permission to read the file, or it's locked
• ERROR_SHARING_VIOLATION: The file is already open by another process with conflicting share modes

Common Root Causes & Fixes #

1. The Program's Working Directory Isn't What You Think #

Just because the file is in the same folder as the executable doesn't mean the program is running with that folder as its working directory. For example:

• If you're debugging from an IDE or debugger, the working directory might be set to the project's root instead of the output folder
• If you launch the exe from a command prompt, the working directory is the prompt's current folder, not the exe's location

Check this: In your debugger, look up the process's current directory (most debuggers have a command or UI for this, or you can use GetCurrentDirectory() in a breakpoint). Compare it to where you created the file.

2. The File Is Locked by Another Process #

Even if you're opening it read-only, if another process has the file open with exclusive access (like a text editor that locks files while editing), CreateFile will fail.

Check this: Use a tool like Process Explorer—search for the filename using the "Find Handle or DLL" feature to see if any other process has it open.

3. Filename Mismatch (Hidden Details) #

Windows filenames are case-insensitive, but there are hidden gotchas:

• Trailing spaces or periods: Windows sometimes trims these from visible filenames, but if CreateFile is using a path with a trailing space, it won't match the actual file
• Unicode vs. ANSI mismatches: If the program is using the wide-character CreateFileW with a filename that has hidden Unicode characters (like full-width spaces), your dir output might not show them
• Extension confusion: Double-check that the filename in CreateFile includes the correct extension (e.g., test.txt vs. test—even if dir shows test.txt, if the call uses test, it won't match)

Check this: Run dir /x to see the short 8.3 filename, and compare it exactly to the path used in CreateFile.

4. Incorrect CreateFile Parameters #

Even if you're requesting read-only access, wrong parameters can break the call:

• dwShareMode: If you set this to 0 (no sharing), and the file is already open (even read-only by another process), you'll get a sharing violation. Use at least FILE_SHARE_READ for read-only opens.
• dwCreationDisposition: Make sure this is set to OPEN_EXISTING—if you use CREATE_NEW or CREATE_ALWAYS, it will fail because the file already exists.
• dwFlagsAndAttributes: Avoid setting flags like FILE_ATTRIBUTE_DIRECTORY (which tells the function you're trying to open a folder, not a file).

Final Tip #

If you can share the exact CreateFile parameters from your disassembly (the values passed to each argument), that would make troubleshooting even more precise. But starting with the steps above should help you narrow down the issue.

内容的提问来源于stack exchange，提问作者Mohammed Janati Idrissi