{"id":93455,"date":"2016-05-13T07:00:00","date_gmt":"2016-05-13T21:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/?p=93455"},"modified":"2019-03-13T11:03:04","modified_gmt":"2019-03-13T18:03:04","slug":"20160513-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20160513-00\/?p=93455","title":{"rendered":"Why am I being told that my message ID is too large?"},"content":{"rendered":"

A customer asked for help with an error message in the message compiler. <\/p>\n

\n

Our message file goes like this: <\/p>\n

\nMessageIdTypedef=DWORD\nMessageId = 0x10001\nSymbolicName = MSG_ERROR\nLanguage = English\nError %1\n.\n<\/pre>\n
When we compile it, we get this error: <\/p>\n
\nMC : error : Message Id value (10001) too large\n<\/pre>\n
Our understanding is that we defined our message ID as a DWORD<\/code> (which is an unsigned 32-bit integer), and the value 0x10001<\/code> easily fits inside an unsigned 32-bit integer. Is there a command line switch we need to pass to mc.exe<\/code>? What are we missing? <\/p>\n<\/blockquote>\n
What they’re missing is that message identifiers are limited to the range 0 through 65535. <\/p>\n
One place this limitation is visible is in the header file generated by the message compiler: <\/p>\n
\n\/\/\n\/\/  Values are 32 bit values laid out as follows:\n\/\/\n\/\/   3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1\n\/\/   1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0\n\/\/  +-+-+-+-+-+---------------------+-------------------------------+\n\/\/  |S|R|C|N|r|    Facility         |               Code            |\n\/\/  +-+-+-+-+-+---------------------+-------------------------------+\n\/\/\n\/\/  where\n\/\/\n\/\/      S - Severity - indicates success\/fail\n\/\/\n\/\/          0 - Success\n\/\/          1 - Fail (COERROR)\n\/\/\n\/\/      R - reserved portion of the facility code, corresponds to NT's\n\/\/              second severity bit.\n\/\/\n\/\/      C - reserved portion of the facility code, corresponds to NT's\n\/\/              C field.\n\/\/\n\/\/      N - reserved portion of the facility code. Used to indicate a\n\/\/              mapped NT status value.\n\/\/\n\/\/      r - reserved portion of the facility code. Reserved for internal\n\/\/              use. Used to indicate HRESULT values that are not status\n\/\/              values, but are instead message ids for display strings.\n\/\/\n\/\/      Facility - is the facility code\n\/\/\n\/\/      Code - is the facility's status code\n\/\/\n<\/pre>\n
Observe that the Code<\/code> field is a 16-bit value. <\/p>\n
A copy of this header block is also included in the documentation on event identifiers<\/a>. Though you have to realize that the thing that the message compiler spits out are event identifiers. <\/p>\n
The 16-bit limit is also called out in the C# version of the trace logging interface: Event­Attribute.Event­Id<\/code><\/a> says that “This value should be between 0 and 65535.” <\/p>\n
But again, this requires that you realize that message files are related to event logging. <\/p>\n
One thing that may nudge you to that realization is that the documentation for Message Files<\/a> is in the Event Logging<\/i> section of MSDN, and it opens with the sentence, “Each event source<\/a> should register message files that contain…” <\/p>\n
But perhaps the smoking gun is that the documentation for the Message File syntax says Any value specified must fit in 16 bits<\/a>. <\/p>\n","protected":false},"excerpt":{"rendered":"
Look at the message format.<\/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-93455","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Look at the message format.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/93455","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=93455"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/93455\/revisions"}],"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=93455"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=93455"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=93455"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}