I don't see anything wrong with your example code.
May I humbly suggest that you check the PROTO for the wide version of the function?
There's a lot of bugs in MASM header files, most people fix them silently so the rest of us remain unaware of them.
This is especially true of Wide functions, because most MASM users tend not to use wide strings when they can avoid it - it's a perversion, and it is an epidemic.

Posted on 2011-01-08 23:48:52 by Homer
When I run your exe, debugger is showing a reference to a null pointer that caused a GPF - I repeat to check the proto, since you passed no zero params.
Posted on 2011-01-09 02:10:34 by Homer

I INCLUDEd the file C:\MASM32\include\strsafe.INC, which contains the following line; StringCbPrintfW PROTO C  :DWORD ,:DWORD ,:DWORD , :VARARG .  I would think that if MASM could not find the PROTO for that call, it would squawk.  As far as I can see, Ollydbg shows a good call.

Posted on 2011-01-09 12:51:30 by Ratch
A bit of digging around and I found that the suggested fix is to use "%S" rather than "%s" in your format string.
Try it, if that works I'll be very amused indeed :P
Also to let you know I stepped through the function in Olly, there's definitely a GPF caused by a null pointer reference but it's nothing to do with your code and occurs inside NTDLL, protected by a SEH so you probably didn't notice it before.
Posted on 2011-01-09 21:01:01 by Homer

A bit of digging around and I found that the suggested fix is to use "%S" rather than "%s" in your format string.

I came across that "fix", too.  I tried it a while back before I posted my problem here, and it did not work.  Doesn't work now, either.  My output is a single capital "S".

Posted on 2011-01-09 22:04:42 by Ratch
szText WORD 4f52h, 4b41h, 4e20h, 474fh, 21h
works too without the spaces and it auto null terminates.  masm is low level, so that you can test for wide char and double up on values in the words if you are necessarily inclined.  low level has pluses and minuses.  this may be a minus in your situation.
Posted on 2011-01-10 12:03:43 by roaknog

I am not too impressed with your method.  All StringCbVPrintfW is doing in your example is reading the text string as 8-bit ASCII code, which it should not be doing.  How about something that uses UNICODE characters that need 16-bit representation like the example below.  I don't think you will be able to use StringCbVPrintfW for that.  I had to use  wvsprintfW to get the results in the example.  The text string for the example is szText WORD 'R',0305H,'O',0305H,'A',0305H,'K',0305H,'N',0305H,'O',0305H,'G',0305H,0

Posted on 2011-01-11 00:00:03 by Ratch