1

我正在编写一个应用程序，它通过 Windows RPC 机制与另一个进程中的托管接口进行通信。

编组是通过标准的内置 NDR 处理的。该接口公开了几个函数，其中一个UNICODE_STRING通过参数返回字符串 ( )。

该函数在成功时返回 0，否则返回错误代码。现在，当我调用 RPC 函数时，它成功并填充了 UNICODE_STRING 参数。

问题是 C++ 或运行时在尝试读取函数返回的字符串时吞下了一个错误。为了节省您阅读大量代码，这是我的代码的缩写版本：

void func()
{
    UNICODE_STRING unicode_str;

    HMODULE hLib = LoadLibrary(L"Ntdll.dll");
    RtlInitUnicodeStringFn fn;

    fn = (RtlInitUnicodeStringFn) GetProcAddress(hLib, "RtlInitUnicodeString");
    fn(&unicode_str, NULL);

    std::cout << "Before calling RPC the buffer was pointing at: " << std::hex << unicode_str.Buffer << std::endl;

    if(call(binding.get_binding_handle(), &unicode_str))
    {
        std::cout << "len: " << unicode_str.Length << " maxlen: " << unicode_str.MaximumLength << std::endl;
        std::cout << "After calling RPC the buffer is pointing at: " << std::hex << unicode_str.Buffer << std::endl;
        try
        {
            for(int i = 0; i < unicode_str.Length; i++)
                std::wcout << i << ": " << unicode_str.Buffer[i] << std::endl;
        }
        catch(...)
        {
            std::cout << "Caught an exception";
        }
        std::wcout << "I won't be written" << std::endl;
    }
}

bool call(void* handle, PUNICODE_STRING str)
{
    __try
    {
        std::cout << "RPC call returned: " << RpcInterfaceFunction(handle, str) << std::endl;
        return true;
    }
    __except(1)
    {
        std::cout << "Error: " << std::dec << GetExceptionCode() << std::endl;
        return false;
    }
}

执行此代码后，输出为：

Before calling RPC the buffer is pointing at : 000000000
RPC call returned: 0
len:68, maxlen: 70
After calling RPC the buffer is pointing at: 00746168
0: #
1: t
2:

并返回。我已经通过这个函数使用了一个调试器，它正确地遍历了整个 68 个字符（不管缓冲区中有什么 - 它是垃圾数据）并正确地进入最后一个I won't be writtenwcout 指令。我想知道问题是否与控制台无法处理的不可读字符有关，这些字符可能会改变下一个字符的行为或控制台光标 - 这会使输出不可见，但不是 - 我已经交换了输出流并设置它到一个文件 (wofstream) 并且文件的大小是 47 字节 - 这与写入控制台流的大小完全相同。

我没有遇到任何访问冲突、任何异常、任何日志条目，什么都没有。即使调试器（VS2010）在选择中断每种可能的异常类型后也没有注意到任何异常 - 更令人惊讶的是，使用调试器单步执行代码并观察那里的本地人会产生预期值（我从 0到 68 并且缓冲区中的当前 wchar_t 有一个值（垃圾 unicode char）。

有人可以解释这种行为吗？

编辑：

交换打印循环：

for(int i = 0; i < unicode_str.Length; i++)
{
    std::wcout << "I'm writing the " << i << "th character" << std::endl;
    unsigned short temp = unicode_str.Buffer[i];
    std::wcout << i << ": " << temp << std::endl;
}

正确打印temp67 的值。

但是，为什么打印这些字符的 wchar_t 版本会阻止输出流接受任何内容？

4

2 回答 2

3

您确定它unicode_str包含有效的 Unicode 数据吗？

我对std::wcout（和std::wostream一般的 s）的经验是，每当他们获得无效的 Unicode 数据时，他们就会陷入糟糕的状态。默认情况下，发生这种情况时它们不会抛出异常：它们只是设置内部故障位或坏位并停止工作。std::wcout.fail()您可以通过调用或检查流是否处于错误状态std::wcout.bad()，并且可以通过调用清除错误状态标志std::wcout.clear()。

此外，如果您希望在设置了 failbit 或 badbit 时引发异常，您可以调用std::wcout.exceptions(std::wostream::failbit | std::wostream::badbit).

所以底线是我建议不要std::wostream为此使用 s 。我希望这可以帮助您解决问题。

于 2011-12-24T16:49:25.803 回答
2

实际上，我有足够的信心，这是您的问题，我将把它作为答案而不是在评论中提出问题。

大多数时候，当 aniostream的行为令人费解时，这是因为failbitor eofbit（或有时badbit）被设置了。当处于这些不良状态之一时，I/O 操作通常（总是？）会立即返回而不做任何事情。

我认为错误的 unicode 数据会导致failbit或被badbit设置。

作为一般的调试原则，当我看到一个iostream神秘的行为时，我检查的第一件事就是确保流仍然是好的。几乎每次，我发现流实际上并不好，完全解释了神秘的行为。

一旦你知道流是坏的，你可以决定采取一些行动。对于坏的 unicode 数据，也许只需将流的状态重置回一个好的状态就足够了——我对 unicode I/O 的了解不够确定。

于 2011-12-24T17:06:36.823 回答