RtlIntegerToUnicodeString returns STATUS_BUFFER_OVERFLOW

ULONG MyNumber = 0xc3072e18;

MyString->MaximumLength = (sizeof (ULONG) * 8 * sizeof (WCHAR)) + sizeof (UNICODE_NULL) ; // 66 bytes = (size of ULONG in bits * sizeof WCHAR) + sizeof WCHAR NULL

MyString->Buffer = ExAllocatePool (PagedPool, MyString->MaximumLength);

status = RtlIntegerToUnicodeString (MyNumber, 2, MyString);

I get status = STATUS_BUFFER_OVERFLOW.

Then I read the following link which says “The native function does this when the string would be longer than 16 characters even when the string parameter is long enough.”

http://source.winehq.org/WineAPI/RtlIntegerToUnicodeString.html

Is there a real bug or I’m doing something wrong? THanks.

xxxxx@yahoo.com wrote:

ULONG MyNumber = 0xc3072e18;

MyString->MaximumLength = (sizeof (ULONG) * 8 * sizeof (WCHAR)) + sizeof (UNICODE_NULL) ; // 66 bytes = (size of ULONG in bits * sizeof WCHAR) + sizeof WCHAR NULL

MyString->Buffer = ExAllocatePool (PagedPool, MyString->MaximumLength);

status = RtlIntegerToUnicodeString (MyNumber, 2, MyString);

I get status = STATUS_BUFFER_OVERFLOW.

Then I read the following link which says “The native function does this when the string would be longer than 16 characters even when the string parameter is long enough.”

http://source.winehq.org/WineAPI/RtlIntegerToUnicodeString.html

It’s true. If you disassemble RtlIntegerToUnicodeString, you’ll see
that it calls RtlIntegerToChar and limits the maximum length to 16
characters.

Is there a real bug or I’m doing something wrong?

I wouldn’t call it a bug. I’d call it an undocumented limitation. It’s
trivially easy to convert a string to binary in your own code. Why do
you need to do that in a driver, anyway?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Tim Roberts wrote:

If you disassemble RtlIntegerToUnicodeString, you’ll see
that it calls RtlIntegerToChar and limits the maximum length to 16
characters.

I wouldn’t call it a bug. I’d call it an undocumented limitation.

The function accepts the value as an IN ULONG parameter for which the
doc states “Specifies the ULONG value to convert.”

*If* this works as expected for 32bit numbers with any Base!=2, *then* I
definitely would call it a bug. *Else* it is a documentation error not
to mention that the function implicitly assumes Integers to be 16bit.

Yes, this is a bug. This routine is currently not really useful with the base==2 if chance exist that result string is going to exceed 16 symbols.