Reverse Engineering Citrix ThinWire
2009 (0x7D9) - The Year of Debugging
Crash dumps (and live debugging) can be very useful for reverse engineering component dependencies. Let’s look at MS Video Driver Architecture UML component diagram (synthesized after reading various articles from OSR and DDK):

Coupled with this understanding and armed with Citrix symbol files (which are freely downloadable from Citrix support and you don’t really need them to see component dependencies) I was able to transform this thread stack below and other similar stacks into the following UML component diagram (some functions are shown as module!xxx and offsets are removed for clarity):
nt!KiSwapContext
nt!KiSwapThread
nt!KeWaitForSingleObject
tcpip!xxx
tcpip!TCPDispatch
nt!IofCallDriver
nt!xxx
nt!xxx
TDTCP!xxx
TDTCP!xxx
TDTCP!TdIoctl
termdd!_IcaCallSd
termdd!IcaCallNextDriver
pdrframe!xxx
pdrframe!PdIoctl
termdd!_IcaCallSd
termdd!IcaCallNextDriver
pdcrypt1!xxx
pdcrypt1!PdIoctl
termdd!_IcaCallSd
termdd!IcaCallNextDriver
WDICA!xxx
WDICA!xxx
WDICA!xxx
WDICA!xxx
WDICA!xxx
WDICA!xxx
WDICA!WdIoctl
termdd!IcaCallStack
termdd!IcaCallDriver
termdd!IcaDeviceControlChannel
termdd!IcaDeviceControl
termdd!IcaDispatch
win32k!GreDeviceIoControl
win32k!EngDeviceIoControl
vdtw30!xxx
vdtw30!xxx
win32k!vMovePointer
win32k!GreMovePointer
win32k!xxxMoveEventAbsolute
win32k!ProcessMouseInput
win32k!InputApc
nt!KiDeliverApc
nt!KiSwapThread
nt!KeWaitForMultipleObjects
win32k!xxxMsgWaitForMultipleObjects
win32k!xxxDesktopThread
win32k!xxxCreateSystemThreads
win32k!NtUserCallOneParam
nt!KiSystemServiceCopyEnd
nt!KiSwapThread
nt!KeWaitForSingleObject
win32k!EngWaitForSingleObject
vdtw30!xxx
vdtw30!xxx
vdtw30!xxx
vdtw30!DrvTw2SaveScreenBits
win32k!GreSaveScreenBits
win32k!CreateSpb
win32k!zzzChangeStates
win32k!zzzBltValidBits
win32k!xxxEndDeferWindowPosEx
win32k!xxxSetWindowPos
win32k!xxxShowWindow
win32k!NtUserShowWindow
nt!KiSystemService
USER32!NtUserShowWindow
USER32!InternalDialogBox
USER32!DialogBoxIndirectParamAorW
USER32!DialogBoxParamW
We replace MS components with Citrix ones:
- Video Display with vdtw30.dll
- Video Miniport with icacdd.sys
- Hardware and HAL with Terminal Services stack components (MS termdd.sys, Citrix wdica.sys, etc)

- Dmitry Vostokov -
_1125.png)
New Books:
DLL List Landscape: The Art from Computer Memory Space
Dumps, Bugs and Debugging Forensics: The Adventures of Dr. Debugalov
WinDbg: A Reference Poster and Learning Cards
Memory Dump Analysis Anthology, Volume 2
Also available:
Memory Dump Analysis Anthology, Volume 1
New Children's Book:
November 5th, 2006 at 11:00 am
The diagram is slightly inaccurate. The video driver only ever directly links against WIN32K and would not call VideoPort.Sys directly without going through WIN32K. There is also another Citrix related path missing which I would not be able to mention in a public forum.
November 5th, 2006 at 2:45 pm
Thanks for pointing this out! This was adopted from the picture in OSR article:
From Andy’s Bookshelf: So you Wanna Write a Video Driver?
Figure 2 - DDI and Miniport Drivers
http://www.osronline.com/article.cfm?id=66
I’ll add a label to that link: “via win32k!EngDeviceIoControl” similar I’ve done for vdtw30.dll and termdd.sys interaction
Thanks,
Dmitry
November 5th, 2006 at 6:29 pm
No problem. The video display driver also directly accesses the hardware and performs things such as DMA transfers. This helps speed things up as it then doesn’t require the display driver to send an IRP to the miniport for every graphic command.
http://www.codeproject.com/system/driverdev6asp.asp
March 1st, 2007 at 5:41 pm
Corrected both diagrams (removed direct link from video display driver to video port driver)
Thanks,
Dmitry