Win32程序调用GetOpenFileName崩溃 返回错误码1008问题咨询

错误码1008对应通用对话框错误CDERR_BUFFERTOOSMALL，崩溃和报错的核心原因是ANSI/Unicode字符类型不匹配：

• 你的Win32项目默认采用Unicode字符集配置，头文件中GetOpenFileName宏会展开为宽字符版本GetOpenFileNameW，该版本要求lpstrFile字段指向wchar_t类型的宽字符缓冲区，nMaxFile字段要求传入缓冲区可容纳的宽字符个数。
• 你代码中定义的Filestring是单字节char类型数组，总字节数为MAX_PATH，却通过强制类型转换伪装成宽字符指针传入接口。接口按宽字符规则计算缓冲区可用长度时，实际可用空间仅为要求值的1/2，判定缓冲区过小抛出1008错误，后续写入文件名时触发内存越界直接导致程序崩溃。

两种方案选择其一即可，优先推荐Unicode方案，符合Win32现代开发规范。

方案1：适配Unicode字符集（推荐） #

将缓冲区改为宽字符类型，移除错误的强制类型转换，所有传给结构体的字符串统一使用宽字符串：

wchar_t Filestring[MAX_PATH] = L"\0";
OPENFILENAME ofn = { 0 };
ofn.lStructSize = sizeof(OPENFILENAME);
ofn.lpstrFile = Filestring;
ofn.nMaxFile = MAX_PATH;
// 按需补全其他配置，例如过滤器、所属窗口句柄等
// ofn.lpstrFilter = L"文本文件\0*.txt\0所有文件\0*.*\0";
// ofn.hwndOwner = hWnd;
if (GetOpenFileName(&ofn) == TRUE)
{
    // 选择文件后的业务逻辑
}
else
{
    int err = CommDlgExtendedError();
    // 错误处理逻辑
}

方案2：显式使用ANSI版本接口 #

如果业务场景不需要Unicode支持，可明确调用ANSI版本的接口和对应结构体，无需修改缓冲区类型：

char Filestring[MAX_PATH] = "\0";
OPENFILENAMEA ofn = { 0 };
ofn.lStructSize = sizeof(OPENFILENAMEA);
ofn.lpstrFile = Filestring;
ofn.nMaxFile = MAX_PATH;
// 按需补全其他配置，字符串使用普通char字符串即可
// ofn.lpstrFilter = "文本文件\0*.txt\0所有文件\0*.*\0";
// ofn.hwndOwner = hWnd;
if (GetOpenFileNameA(&ofn) == TRUE)
{
    // 选择文件后的业务逻辑
}
else
{
    int err = CommDlgExtendedError();
    // 错误处理逻辑
}

注意：OPENFILENAME结构体本身也会随字符集宏在OPENFILENAMEA和OPENFILENAMEW之间切换，禁止将不同字符集的结构体、函数、字符串混用，否则会因内存布局不匹配触发各类异常。

内容的提问来源于stack exchange，提问作者prod