IOCTL_AFD_SET_CONTEXT data structure does not match known format

[derekbruening]

From [email protected] on May 04, 2011 14:01:19

the SOCKET_CONTEXT structure doesn't seem to match what I observe being used by winsock for IOCTL_AFD_SET_CONTEXT on both XP and win7: beyond SOCK_SHARED_INFO the fields are all different. this case covers investigating.

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

[derekbruening]

From [email protected] on May 09, 2011 14:49:48

This issue was closed by revision r287 .

Status: Fixed

[derekbruening]

From [email protected] on May 27, 2011 05:45:55

Are you sure your fix was correct?

On XP32 with the test from issue #412 :
context[104...108] = 0x00000068 = 104
insz = 248 = 104 + 144
144 = sizeof(SOCKET_CONTEXT) before the change

[derekbruening]

From [email protected] on May 27, 2011 05:55:21

And on W7 x64
context[120...124] = 0x00000004 = 4
insz = 164 = 4 + 160
160 = sizeof(SOCKET_CONTEXT) after the change.

Are you sure that the XP you were testing was x64?

[derekbruening]

From [email protected] on May 27, 2011 08:03:33

perhaps the original struct is what 5.1 and earlier use. xp64 is based on 5.2 (win2003). weird that they'd break backward compatibility, even at winsock level.

[derekbruening]

From [email protected] on May 27, 2011 08:15:53

(How) Can we if/else the code to take that into account?

[derekbruening]

From [email protected] on May 27, 2011 08:25:37

two structs and perhaps clean up version checking with DRi#304

re-opening issue

Status: Accepted

[derekbruening]

From [email protected] on May 27, 2011 12:26:24

FTR, here's a word-by-word diff of the SOCKET_CONTEXT contents on XP32 and W7_64:
$ diff -u wxp.words w7.words
--- wxp.words
+++ w7.words
@@ -9,8 +9,8 @@
word[28] = 0x00000000
word[32] = 0x00000000
word[36] = 0x00002000

• word[40] = 0x0000fc00
• word[44] = 0x00000000
• word[40] = 0x00002000
• word[44] = 0x00001000 // Hmmm there are only 12 bits defined in the flags struct
  word[48] = 0x00000001
  word[52] = 0x000003ea
  word[56] = 0x00020609
  @@ -25,43 +25,22 @@
  word[92] = 0x00000000
  word[96] = 0x00000000
  word[100] = 0x00000000
• word[104] = 0x00000068
• word[108] = 0xffffffff
• word[112] = 0x00000000
• word[116] = 0x00000000
• word[120] = 0x00000000
• word[124] = 0x00000000
• word[104] = 0xe70f1aa0
• word[108] = 0x11cfab8b
• word[112] = 0x8000a38c
• word[116] = 0x92a1485f
• word[120] = 0x00000004
• word[124] = 0x00000011
  word[128] = 0x00000000
  word[132] = 0x00000000
  word[136] = 0x00000000
  word[140] = 0x00000000
• word[144] = 0x00000002
• word[148] = 0x00000002
• word[152] = 0x00000011
• word[156] = 0x00002000
• word[160] = 0x00000001
• word[164] = 0x00000001
• word[168] = 0x00000000

- word[188] = 0x00000000 - word[192] = 0x00000100 - word[196] = 0x00000100 - word[200] = 0x00000001 - word[204] = 0x00000020 - word[208] = 0x00000000 - word[244] = 0x00000000 - word[144] = 0x00000000 - word[148] = 0x00000000 - word[152] = 0x00000000 - word[156] = 0x00000000 - word[160] = 0x00000002 sizeof(SOCK_SHARED_INFO) = 104, sizeof(GUID) = 16 sizeof(SOCKADDR) = 16, offsetof(SOCK_SHARED_INFO, SizeOfSendBuffer) = 40 -SizeOfHelperData = 104, helper_offs = 144 -sizeof(SOCKET_CONTEXT) = 144, insz = 248 +SizeOfHelperData = 4, helper_offs = 160 +sizeof(SOCKET_CONTEXT) = 160, insz = 164

[derekbruening]

From [email protected] on May 27, 2011 12:34:28

XP bytes [112...128) = zeroes
match W7[128...140) = presumably local address?

XP [128...140) = zeroes
match W7 [144...160) = presumably remote address?

Also, XP[144] = 0x02 = W7[160]

Looks like the +16 offset is constant - WDYT?

Maybe the 13th byte means "do we put in the GUID?" (just a speculation)

Anyways, I think we should add
ASSERT(sizeof(SOCKET_CONTEXT) + SizeOfHelperData == insz);
and run the test on as many Windows versions as we can.

// btw, in comment #2 I meant issue #421 , not issue #412 .

[derekbruening]

From [email protected] on May 27, 2011 14:45:06

feel free to take over as this is not my highest priority and I won't get to it for a bit. note that originally I tracked the data from WSAPROTOCOL_INFO at WSPSocket() to the syscall on xp64 and win7x64 and confirmed that the GUID was a real guid: matches the provider id in the winsock catalog. we should see exactly what happens to the guid on xp32, and look at perhaps 2K, etc. and winsock version fields to see what the real trigger is.

also note that on xp64 w/ issue #68 app 2 subpieces of the helper data were uninit.

[derekbruening]

From [email protected] on May 27, 2011 18:40:23

Owner: ---

[derekbruening]

From [email protected] on May 29, 2011 23:59:37

Issue 421 has been merged into this issue.

[derekbruening]

From [email protected] on May 30, 2011 00:03:27

OK, taking over.

FTR, on Windows Server 2008 x64 (pre- R2 ), the SOCKET_CONTEXT values match those of W7 x64.

Status: Started
Owner: [email protected]

[derekbruening]

From [email protected] on June 01, 2011 04:41:02

Should be fixed by r314 except for the unknown HelperData format (splitted into issue #424 )

Status: Fixed