java-native-access/jna · error · UnsupportedOperationException

Unable to extract version info from the file

Error message

Unable to extract version info from the file: "<filePath>"

What it means

VersionUtil.getFileVersionInfo calls the Win32 VerQueryValue function to extract the VS_FIXEDFILEINFO version block from a file's version resource. When VerQueryValue returns FALSE, the file's version information cannot be parsed, and this UnsupportedOperationException is thrown with the file path.

Solutions

  1. Verify the target file actually contains a version resource (e.g. right-click → Properties → Details in Explorer) before calling
  2. Check VersionUtil.getFileVersionInfoSize / GetFileVersionInfoSizeW returns > 0 and handle 0 as 'no version info' instead of treating it as an error
  3. Point the call at the correct binary — a path typo may resolve to a resource-less file
  4. Wrap the call in try/catch for UnsupportedOperationException and fall back to null/skip

Example fix

// before
VS_FIXEDFILEINFO info = VersionUtil.getFileVersionInfo(path);
// after
VS_FIXEDFILEINFO info;
try {
    info = VersionUtil.getFileVersionInfo(path);
} catch (UnsupportedOperationException e) {
    info = null; // file has no version resource
}
Defensive patterns

Strategy: try-catch

Validate before calling

if (!file.exists() || file.length() == 0) {
    throw new IllegalArgumentException("File missing or empty: " + file);
}
int size = Version.INSTANCE.GetFileVersionInfoSize(file.getAbsolutePath(), null);
boolean hasVersionInfo = size > 0;

Try / catch

try {
    VS_FIXEDFILEINFO info = VersionUtil.getFileVersionInfo(path);
} catch (UnsupportedOperationException e) {
    VS_FIXEDFILEINFO info = null; // no version resource
}

Prevention

When it happens

Trigger: Calling VersionUtil.getFileVersionInfo(filePath) on a file that has no version resource at all, has a malformed/corrupt version resource, or on a non-PE file; also when GetFileVersionInfoSize succeeded but the buffer layout is invalid.

Common situations: Inspecting version info of DLLs/EXEs that legitimately carry no VERSIONINFO resource (many third-party or MinGW-built binaries); passing a .sys driver or data file; corrupted system files.

Understand the failure class

Background: "failed to read file", EACCES, ENOENT and "could not read <path>" errors: when a program can't read a file from disk — this error's family across 49 libraries.

Related errors


AI-assisted analysis of java-native-access/jna@d036ad9781 (2026-09-12). Data as JSON: /api/errors/1a6fe304901471f3. Report an issue: GitHub.

Appendix: source

Thrown at contrib/platform/src/com/sun/jna/platform/win32/VersionUtil.java:80

            throw new Win32Exception(Native.getLastError());
        }

        // buffer to hold version info
        Pointer lpData = new Memory(versionLength);

        // pointer to pointer to location in aforementioned buffer
        PointerByReference lplpBuffer = new PointerByReference();

        if (!Version.INSTANCE.GetFileVersionInfo(filePath, 0, versionLength, lpData)) {
            throw new Win32Exception(Native.getLastError());
        }

        // here to make VerQueryValue happy.
        IntByReference puLen = new IntByReference();

        // this does not set GetLastError, so no need to throw a Win32Exception
        if (!Version.INSTANCE.VerQueryValue(lpData, "\\", lplpBuffer, puLen)) {
            throw new UnsupportedOperationException("Unable to extract version info from the file: \"" + filePath + "\"");
        }

        VS_FIXEDFILEINFO fileInfo = new VS_FIXEDFILEINFO(lplpBuffer.getValue());
        fileInfo.read();
        return fileInfo;
    }

}

View on GitHub (pinned to d036ad9781)