使用Java FFM的Linker.Option.captureCallState无法成功捕获Windows平台的GetLastError值

我来帮你排查这个问题——你遇到的情况主要是两个细节没处理到位：一是宽字符串的构造有错误，二是对captureCallState的实际效果验证需要结合正确的Native参数传递。

1. 核心问题：无效的宽字符串导致GetLastError值异常 #

你代码里构造lpLibName的逻辑有个关键漏洞：Windows的LoadLibraryW要求传入以null（0x0000）终止的宽字符串，但你只复制了nonexist的字符内容，没有在内存段末尾添加终止符，而且字符数组的复制方式存在布局兼容的隐式问题：

// 原代码的问题点
char[] libName = "nonexist".toCharArray();
MemorySegment lpLibName = arena.allocate(ValueLayout.JAVA_SHORT, libName.length + 1);
lpLibName.copyFrom(MemorySegment.ofArray(libName));

MemorySegment.ofArray(libName)对应的是ValueLayout.JAVA_CHAR布局，而lpLibName用的是ValueLayout.JAVA_SHORT，虽然两者都是16位，但直接copyFrom会按字节复制，更重要的是最后一个预留的short位置没有设为0，导致LoadLibraryW会读取内存中后续的随机数据，直到遇到0字节——这种情况下，函数返回NULL时的GetLastError可能不会被正确设置（甚至返回0）。

2. 修正方案：正确构造宽字符串+验证捕获逻辑 #

我们先修正宽字符串的构造，再确保captureCallState的使用完全正确：

修正后的完整代码

import java.lang.foreign.*;
import java.lang.invoke.MethodHandle;
import java.lang.invoke.VarHandle;

public final class Drill {
    public static void main(String[] args) throws Throwable {
        System.loadLibrary("kernel32");
        Linker nativeLinker = Linker.nativeLinker();
        SymbolLookup combinedLookup = SymbolLookup.loaderLookup().or(nativeLinker.defaultLookup());
        
        // 简化符号查找逻辑
        MemorySegment pfnLoadLibraryW = combinedLookup.find("LoadLibraryW")
                .orElseThrow(() -> new RuntimeException("Failed to find LoadLibraryW symbol"));

        // 构建downcall handle，启用GetLastError捕获
        MethodHandle hLoadLibraryW = nativeLinker.downcallHandle(
                pfnLoadLibraryW,
                FunctionDescriptor.of(
                        ValueLayout.ADDRESS, // 返回HMODULE
                        ValueLayout.ADDRESS.withTargetLayout(ValueLayout.JAVA_SHORT) // LPCWSTR参数
                ),
                Linker.Option.captureCallState("GetLastError")
        );

        try (Arena arena = Arena.ofConfined()) {
            // 正确构造null-terminated的宽字符串
            String libName = "nonexist";
            MemorySegment lpLibName = arena.allocateFrom(
                    ValueLayout.ADDRESS.withTargetLayout(ValueLayout.JAVA_SHORT),
                    libName
            );

            // 分配捕获状态的内存段
            StructLayout captureStateLayout = Linker.Option.captureStateLayout();
            MemorySegment capturedState = arena.allocate(captureStateLayout);

            // 调用Native函数，注意参数顺序：业务参数在前，捕获状态在后
            MemorySegment result = (MemorySegment) hLoadLibraryW.invokeExact(lpLibName, capturedState);

            if (!result.equals(MemorySegment.NULL)) {
                throw new RuntimeException("Unexpectedly loaded nonexistent library");
            }

            // 解析捕获的GetLastError值
            VarHandle vh = captureStateLayout.varHandle(MemoryLayout.PathElement.groupElement("GetLastError"));
            int lastError = (int) vh.get(capturedState, 0L);
            System.out.println("GetLastError = " + lastError); // 应该返回126（ERROR_MOD_NOT_FOUND）或2（ERROR_FILE_NOT_FOUND）
        }
    }
}

3. 关键修正点说明 #

• 宽字符串构造：用arena.allocateFrom直接从Java String生成符合要求的宽字符串，自动处理终止符，避免手动复制的错误。
• 符号查找简化：用SymbolLookup.or()合并loaderLookup和stdlibLookup的查找逻辑，更简洁可靠。
• 捕获状态解析：确认captureStateLayout的字段名确实是GetLastError（Windows平台下captureCallState("GetLastError")会生成对应字段），通过VarHandle正确读取线程本地的错误码。

4. 为什么原代码返回0？ #

当传入的宽字符串没有终止符时，LoadLibraryW会读取内存中后续的随机数据，直到遇到0。这种情况下，系统可能无法识别这是一个有效的库名请求，甚至不会设置GetLastError，或者错误码被后续的JVM内部操作覆盖——而captureCallState的设计就是为了避免JVM操作覆盖错误码，但前提是Native函数本身确实设置了错误码。

运行修正后的代码，你应该能得到预期的错误码（比如126，表示找不到指定的模块）。

内容来源于stack exchange