{"id":112514,"date":"2026-07-10T07:00:00","date_gmt":"2026-07-10T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=112514"},"modified":"2026-07-04T07:18:34","modified_gmt":"2026-07-04T14:18:34","slug":"20260710-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20260710-00\/?p=112514","title":{"rendered":"The case of the mysterious changes to integers when there shouldn’t have been any code generation effect"},"content":{"rendered":"

A colleague made some code changes that should not have had any effect on the generated binary. Specifically, they migrated from the NDIS_STRING_CONST<\/code> macro<\/a> to the more type-safe RTL_CONSTANT_STRING<\/code> macro<\/a>. The two macros produce the same results at the end of the day, so the expectation was that this would not result in any change to the binary.<\/p>\n

But they found a change to the binary.<\/p>\n

Specifically, four functions changed, and what is particularly strange is that none of them involved the macro changes. Three of the functions are in one source file, and the fourth is in a source file that wasn’t even touched!<\/p>\n

The changes looked like this:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
Before<\/th>\nAfter<\/th>\n<\/tr>\n
contoso!Evt\u00adWdf\u00adWidget\u00adContext\u00adCleanup<\/tt><\/td>\n<\/tr>\n
mov rax, [contoso!WdfFunctions_01031]<\/tt>
\nlea rcx, [??_C@__0DK@MPBCIIPN@...]<\/tt>
\nmov [rsp+20h], rcx<\/tt>
\nmov r9d, 62Bh<\/span><\/tt>
\nmov r8d, 52467443h<\/tt>
\nmov rcx, [contoso!WdfDriverGlobals]<\/tt>
\nmov rdx, rbx<\/tt>
\nmov rax, [rax+670h]<\/tt>
\ncall __guard_dispatch_call<\/tt><\/td>\n		mov rax, [contoso!WdfFunctions_01031]<\/tt>
\nlea rcx, [??_C@__0DK@MPBCIIPN@...]<\/tt>
\nmov [rsp+20h], rcx<\/tt>
\nmov r9d, 62Ah<\/span><\/tt>
\nmov r8d, 52467443h<\/tt>
\nmov rcx, [contoso!WdfDriverGlobals]<\/tt>
\nmov rdx, rbx<\/tt>
\nmov rax, [rax+670h]<\/tt>
\ncall __guard_dispatch_call<\/tt><\/td>\n<\/tr>\n
contoso!Function2<\/tt><\/td>\n<\/tr>\n
mov rax, [contoso!WdfFunctions_01031]<\/tt>
\nlea rcx, [??_C@__0DK@MPBCIIPN@...]<\/tt>
\nmov [rsp+20h], rcx<\/tt>
\nmov r9d, 616h<\/span><\/tt>
\nmov rcx, [contoso!WdfDriverGlobals]<\/tt>
\nmov r8d, 52467443h<\/tt>
\nmov rdx, rdi<\/tt>
\nmov rax, [rax+668h]<\/tt>
\ncall __guard_dispatch_call<\/tt><\/td>\n		mov rax, [contoso!WdfFunctions_01031]<\/tt>
\nlea rcx, [??_C@__0DK@MPBCIIPN@...]<\/tt>
\nmov [rsp+20h], rcx<\/tt>
\nmov r9d, 615h<\/span><\/tt>
\nmov rcx, [contoso!WdfDriverGlobals]<\/tt>
\nmov r8d, 52467443h<\/tt>
\nmov rdx, rdi<\/tt>
\nmov rax, [rax+668h]<\/tt>
\ncall __guard_dispatch_call<\/tt><\/td>\n<\/tr>\n
contoso!Function3<\/tt><\/td>\n<\/tr>\n
mov rax, [contoso!WdfFunctions_01031]<\/tt>
\nlea rcx, [??_C@__0DK@MPBCIIPN@...]<\/tt>
\nmov [r11-20h], rcx<\/tt>
\nxor r8d, r8d<\/tt>
\nmov rcx, [contoso!WdfDriverGlobals]<\/tt>
\nmov r9d, 35Dh<\/span><\/tt>
\nmov rax, [rax+0DB0h]<\/tt>
\ncall __guard_dispatch_call<\/tt><\/td>\n		mov rax, [contoso!WdfFunctions_01031]<\/tt>
\nlea rcx, [??_C@__0DK@MPBCIIPN@...]<\/tt>
\nmov [r11-20h], rcx<\/tt>
\nxor r8d, r8d<\/tt>
\nmov rcx, [contoso!WdfDriverGlobals]<\/tt>
\nmov r9d, 35Ch<\/span><\/tt>
\nmov rax, [rax+0DB0h]<\/tt>
\ncall __guard_dispatch_call<\/tt><\/td>\n<\/tr>\n
contoso!Function4<\/tt><\/td>\n<\/tr>\n
mov rax, [contoso!WdfFunctions_01031]<\/tt>
\nlea rcx, [??_C@__0DK@MPBCIIPN@...]<\/tt>
\nmov rdx, [rbp+8]<\/tt>
\nmov r9d, 377h<\/span><\/tt>
\nmov [rsp+20h], rcx<\/tt>
\nmov r8d, 49507443h<\/tt>
\nmov rcx, [contoso!WdfDriverGlobals]<\/tt>
\nmov rax, [rax+0DB8h]<\/tt>
\ncall __guard_dispatch_call<\/tt><\/td>\n		mov rax, [contoso!WdfFunctions_01031]<\/tt>
\nlea rcx, [??_C@__0DK@MPBCIIPN@...]<\/tt>
\nmov rdx, [rbp+8]<\/tt>
\nmov r9d, 376h<\/span><\/tt>
\nmov [rsp+20h], rcx<\/tt>
\nmov r8d, 49507443h<\/tt>
\nmov rcx, [contoso!WdfDriverGlobals]<\/tt>
\nmov rax, [rax+0DB8h]<\/tt>
\ncall __guard_dispatch_call<\/tt><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

In all of the cases, the change is that a single integer changed to a value one smaller.<\/p>\n

My colleague asked an LLM to explain this change, and it suggested that the changes were related to control flow guard metadata. Does this make sense?<\/p>\n

It didn’t make sense to me, on two points. First, for the guard dispatch call, the only parameter to control flow guard is the rax<\/tt> register, which is the function being checked. All the other registers contain the parameters to the called function. Since the changes are to the r9d<\/tt> register, they are not related to control flow guard.<\/p>\n

Second, the control flow guard metadata is not stored in code. It’s stored as a data block inside the binary<\/a>.<\/p>\n

So what are we seeing?<\/p>\n

I took a look a Evt\u00adWdf\u00adWidget\u00adContext\u00adCleanup<\/code>.<\/p>\n

void EvtWdfWidgetContextCleanup(_In_ WDFOBJECT Object)\r\n{\r\n    auto widgetContext = GetContextFromWidgetHandle(Object);\r\n    if (widgetContext->NeedsDereference)\r\n    {\r\n        widgetContext->NeedsDereference = FALSE;\r\n        WdfObjectDereferenceWithTag(Object, CONTOSO_WIDGET_TAG);\r\n    }\r\n}\r\n<\/pre>\n
The compiler points to the Wdf\u00adObject\u00adDereference\u00adWith\u00adTag<\/code> as the location of the change. And we see that  it is defined as a macro<\/a>:<\/p>\n
#define WdfObjectDereferenceWithTag(Handle, Tag) \\\r\n        WdfObjectDereferenceActual(Handle, Tag, __LINE__, __FILE__)\r\n<\/pre>\n
which is itself  an inline function: <\/a><\/p>\n
_IRQL_requires_max_(DISPATCH_LEVEL)\r\nVOID\r\nFORCEINLINE\r\nWdfObjectReferenceActual(\r\n    _In_\r\n    WDFOBJECT Handle,\r\n    _In_opt_\r\n    PVOID Tag,\r\n    _In_\r\n    LONG Line,\r\n    _In_z_\r\n    PCCH File\r\n    )\r\n{\r\n    ((PFN_WDFOBJECTREFERENCEACTUAL) WdfFunctions[WdfObjectReferenceActualTableIndex])\r\n        (WdfDriverGlobals, Handle, Tag, Line, File);\r\n}\r\n<\/pre>\n
The last little detail is that  WdfFunctions<\/code> is a macro that expands to WdfFunctions_01031<\/code><\/a>. The WDF header files give each version a unique name so that mismatched versions lead to a linker error rather than undefined behavior at runtime.<\/p>\n
Now we can see how this code maps to the compiler output.<\/p>\n
    mov rax, [contoso!WdfFunctions_01031]   ; WdfFunctions\r\n    lea rcx, [??_C@__0DK@MPBCIIPN@...]      ; Address of something\r\n    mov [rsp+20h], rcx                      ; is the File parameter\r\n    mov r9d, 62Bh                           ; Line parameter\r\n    mov r8d, 52467443h                      ; Tag parameter\r\n    mov rcx, [contoso!WdfDriverGlobals]     ; hard-coded parameter\r\n    mov rdx, rbx                            ; Handle parameter\r\n    mov rax, [rax+670h]                     ; Load the function pointer\r\n    call __guard_dispatch_call              ; Validate and call\u00b9\r\n<\/pre>\n
So the value that changed is the line number<\/i>.<\/p>\n
I went back to the pull request and observed that the pull requested deleted a line from the source file.<\/p>\n
#include <strsafe.h>\r\n#include \"stringutils.h\"<\/span>\r\n<\/pre>\n
Part of the pull request included deleting the no-longer-needed header because it contained a private definition of the NDIS_STRING_CONST<\/code> macro, which the code no longer uses.<\/p>\n
Deleting a line from the source file causes all the line numbers to shift by one!<\/p>\n
So what they were seeing was just a change to the line numbers. No change in functionality.<\/p>\n
If they really wanted to make this a “no binary effect” change, they could replace the #include \"stringutils.h<\/code> with a comment or just leave it as a blank line.<\/p>\n
Or they could just accept that line numbers can change when you change lines.<\/p>\n
Bonus chatter<\/b>: But wait, I said that three of the changes were in one file, the one with the deleted line, but a fourth was in a file that didn’t change at all. What’s that about?<\/p>\n
The fourth function contained a call to a function in the modified file, and link-time code generation decided to inline that call. The changed line number propagated into the inline function and resulted in a code generation change in a file that wasn’t even affected by the pull request.<\/p>\n
\u00b9 Recall that  in the validate-and-call pattern<\/a>, the function pointer is passed in the rax<\/code> register, and everthing else is set up as if you were calling the function yourself.<\/p>\n","protected":false},"excerpt":{"rendered":"
Decoding where those integer came from.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-112514","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Decoding where those integer came from.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/112514","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=112514"}],"version-history":[{"count":1,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/112514\/revisions"}],"predecessor-version":[{"id":112517,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/112514\/revisions\/112517"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=112514"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=112514"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=112514"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}