UNADDR in NtGdiOpenDCW system call when calling CreateTextServices

[derekbruening]

From timurrrr@google.com on July 19, 2011 07:07:33

Repro taken from issue #455 :

#include <windows.h>
#include <richedit.h>
#include <textserv.h>

#pragma comment(lib, "riched20.lib")

int main() {
CreateTextServices(NULL, NULL, NULL); // it fails but it's OK
return 0;
}

[XP 32-bit with symbols]
Error #1: UNADDRESSABLE ACCESS: reading 0x00dbd4ac-0x00dbd4b0 4 byte(s) within 0x00dbd4ac-0x00dbd4b0
@0:00:01.423 in thread 4736
system call NtGdiOpenDCW

0x77f1be2f <GDI32.dll+0xbe2f> GDI32.dll!bCreateDCW
0x77f2c82b <GDI32.dll+0x1c82b> GDI32.dll!CreateICW
0x74e8b9bd <RICHED20.dll+0x5b9bd> RICHED20.dll!CreateTextServices
0x74e7d96b <RICHED20.dll+0x4d96b> RICHED20.dll!CreateTextServices
0x0040101e <test.exe+0x101e> test.exe!main
c:\sandbox\455\test.cpp:8

[w/o symbols]
system call NtGdiOpenDCW

0x77f1be2f <GDI32.dll+0xbe2f> GDI32.dll!EnumFontFamiliesExW
0x77f2c82b <GDI32.dll+0x1c82b> GDI32.dll!CreateICW
0x74e8b9bd <RICHED20.dll+0x5b9bd> RICHED20.dll!CreateTextServices
0x74e7d96b <RICHED20.dll+0x4d96b> RICHED20.dll!CreateTextServices
0x0040101e <test.exe+0x101e> test.exe!main
c:\sandbox\455\test.cpp:8

Also seen on Chromium w/o symbols, looks related:

Error #1: UNINITIALIZED READ: reading 0x003cbe58-0x003cbe5c 4 byte(s) within 0x003cbe58-0x003cbe5c
@0:01:26.148 in thread 2840
system call NtGdiEnumFonts

0x759ec264 <GDI32.dll+0x1c264> GDI32.dll!CreateICW
0x759ec3d9 <GDI32.dll+0x1c3d9> GDI32.dll!EnumFontFamiliesExW
0x726eea4e <RICHED20.dll+0xea4e> RICHED20.dll!CreateTextServices
0x726edc98 <RICHED20.dll+0xdc98> RICHED20.dll!IID_ITextServices
0x726ed54a <RICHED20.dll+0xd54a> RICHED20.dll!IID_IRichEditOleCallback
0x726ee895 <RICHED20.dll+0xe895> RICHED20.dll!CreateTextServices
0x726ee871 <RICHED20.dll+0xe871> RICHED20.dll!CreateTextServices
0x726e220c <RICHED20.dll+0x220c> RICHED20.dll!?
0x75e96238 <USER32.dll+0x16238> USER32.dll!gapfnScSendMessage
0x75e968ea <USER32.dll+0x168ea> USER32.dll!gapfnScSendMessage
0x75ea0ab0 <USER32.dll+0x20ab0> USER32.dll!FillRect
0x75ea0ad6 <USER32.dll+0x20ad6> USER32.dll!CallWindowProcW
0x5d221b87 <chrome.dll+0x1b91b87> chrome.dll!ATL::CWindowImplBaseTWTL::CRichEditCtrlT<ATL::CWindow,ATL::CWinTraits<1342177664,0> >::DefWindowPro
c:\program files (x86)\microsoft visual studio 9.0\vc\atlmfc\include\atlwin.h:3030
0x5d223778 <chrome.dll+0x1b93778> chrome.dll!ATL::CWindowImplBaseTWTL::CRichEditCtrlT<ATL::CWindow,ATL::CWinTraits<1342177664,0> >::WindowProc
c:\program files (x86)\microsoft visual studio 9.0\vc\atlmfc\include\atlwin.h:3089
0x75e96238 <USER32.dll+0x16238> USER32.dll!gapfnScSendMessage
0x75e968ea <USER32.dll+0x168ea> USER32.dll!gapfnScSendMessage
0x75e9cd1a <USER32.dll+0x1cd1a> USER32.dll!GetWindow
0x75e9cd81 <USER32.dll+0x1cd81> USER32.dll!SendMessageW
0x5d21af26 <chrome.dll+0x1b8af26> chrome.dll!ATL::CWindow::SetFont
c:\program files (x86)\microsoft visual studio 9.0\vc\atlmfc\include\atlwin.h:864

Original issue: http://code.google.com/p/drmemory/issues/detail?id=501

[derekbruening]

From bruen...@google.com on July 19, 2011 13:26:18

looks like the # args changed in NtGdiOpenDCW in Vista: an arg was added in the middle

Status: Started
Owner: bruen...@google.com
Cc: -bruen...@google.com

[derekbruening]

From derek.br...@gmail.com on July 20, 2011 13:48:16

This issue was closed by revision r404 .

Status: Fixed

[derekbruening]

From timurrrr@google.com on July 21, 2011 02:49:39

Thanks!

Status: Verified

[derekbruening]

From timurrrr@google.com on July 21, 2011 03:12:17

Ooops, looks like it's still broken on Vista x64, see http://build.chromium.org/p/client.drmemory/builders/win-vista_x64-drm/builds/1149/steps/app_suite_tests/logs/stdio [ RUN ] NtGdiTests.CreateTextServices
:::Dr.Memory:::
:::Dr.Memory::: Error #1: UNADDRESSABLE ACCESS: reading 0x0000001c-0x00000020 4 byte(s) within 0x0000001c-0x00000020
:::Dr.Memory::: @0:00:02.547 in thread 4020
:::Dr.Memory::: system call NtGdiOpenDCW
:::Dr.Memory:::
:::Dr.Memory::: 0x7718e0ef <GDI32.dll+0x1e0ef> GDI32.dll!GetDCOrgEx
:::Dr.Memory::: 0x7718deb9 <GDI32.dll+0x1deb9> GDI32.dll!CreateICW
:::Dr.Memory::: 0x71e4dc64 <RICHED20.dll+0xdc64> RICHED20.dll!?
:::Dr.Memory::: 0x71e4dfbd <RICHED20.dll+0xdfbd> RICHED20.dll!CreateTextServices
:::Dr.Memory::: 0x008d6ec9 <app_suite_tests.exe+0x6ec9> app_suite_tests.exe!NtGdiTests_CreateTextServices_Test::TestBody
:::Dr.Memory::: tests\app_suite\ntgdi_tests_win.cpp:32

Status: Started

[derekbruening]

From bruen...@google.com on July 21, 2011 09:28:46

this makes no sense: where did 0x1c come from?
vista wow64:
system call #0x10df NtGdiOpenDCW
arg 0 = 0x0
arg 1 = 0x0
arg 2 = 0x0
arg 3 = 0x2
arg 4 = 0x1
arg 5 = 0x0
arg 6 = 0x0
arg 7 = 0xb6f65c
arg 8 = 0xb6f7f0
arg 9 = 0x71f851c0
processing pre system call #0x10df NtGdiOpenDCW
pre considering arg 0 8 5
pre considering arg 1 220 5
pre considering arg 2 8 5
pre considering arg 0 0 0
processing post system call #0x10df NtGdiOpenDCW res=0x1f0103b9
post considering arg 0 8 5 0x00000000
post considering arg 1 220 5 0x00000000
post considering arg 2 8 5 0x00000000
post considering arg 0 0 0 0x00000000
replacing shadow special 0x1b740200 block for write @0x0000001c 0
Error #5: UNADDRESSABLE ACCESS: reading 0x0000001c-0x00000020 4 byte(s) within 0x0000001c-0x00000020
@0:00:10.359 in thread 2992
system call NtGdiOpenDCW
0x7718e0ef <GDI32.dll+0x1e0ef> GDI32.dll!GetDCOrgEx

win7 wow64:
system call #0x10da NtGdiOpenDCW
arg 0 = 0x0
arg 1 = 0x0
arg 2 = 0x0
arg 3 = 0x2
arg 4 = 0x1
arg 5 = 0x0
arg 6 = 0x0
arg 7 = 0x164f740
arg 8 = 0x164faf0
arg 9 = 0x6e8a71c0
processing pre system call #0x10da NtGdiOpenDCW
pre considering arg 0 8 5
pre considering arg 1 220 5
pre considering arg 2 8 5
pre considering arg 0 0 0
processing post system call #0x10da NtGdiOpenDCW res=0x38013704
post considering arg 0 8 5 0x00000000
post considering arg 1 220 5 0x00000000
post considering arg 2 8 5 0x00000000
post considering arg 0 0 0 0x00000000
marking 0x164f740-0x164f744 written PUMDHPDEV*

[derekbruening]

From bruen...@google.com on July 21, 2011 09:50:18

cannot repro on my vista x64 vm.

[derekbruening]

From timurrrr@google.com on July 21, 2011 10:59:30

Can you try reproducing it on vm75-m3 ?

[derekbruening]

From bruen...@google.com on July 21, 2011 11:10:25

the "vista wow64" in comment 5 is from vm75-m3 run w/ -verbose 2
need to attach debugger. unable to get graphical login at this time, will have to wait.

[derekbruening]

From timurrrr@google.com on July 21, 2011 11:14:38

unable to get graphical login at this time, will have to wait.
You mean you can't RDP there for some reason?

You can "shutdown -r -t 0 -f" at any time and this will likely restore the RDP availability if it has problems :)

[derekbruening]

From timurrrr@google.com on July 22, 2011 08:35:46

Hmmm the report disappeared from the bot since r408 - r409 ...

Marking as fixed unless it re-appears.

Status: Fixed

[derekbruening]

From bruen...@google.com on October 27, 2013 09:04:15

Re-opening for a simplification to switch to purely table-based:

Now that we have the min+max version support in the number
primary,secondary field, why not handle this via two entries in the table,
one with {0,WIN2K3} and the other with {WINVISTA,0}? Then we can list all
7 (or 8) params here for the non-memarg iterator, and we can get rid of
handle_GdiOpenDCW().

Status: Started
Owner: SDenbo...@gmail.com

[derekbruening]

From bruen...@google.com on October 27, 2013 09:09:32

While at it, the min,max fields could be used for NtGdiHfontCreate as well

[derekbruening]

From SDenbo...@gmail.com on October 31, 2013 14:57:59

Added two entries in the table for NtGdiOpenDCW and NtGdiHfontCreate in r1605 .

Status: Fixed