What is the difference between HRESULT error codes that start with 0x8 and with 0xC?

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}

It's more of a curiosity than anything else. I've been reviewing the HRESULT error codes that many Win32 APIs and Windows components return to signify errors.

If I understand its structure correctly, the most significant bit 31 is the error bit. If it's set, then HRESULT contains an error.

For instance, 0x80004002 is E_NOINTERFACE:

No such interface supported.

But what happens when two of its most significant bits are set as in 0xC0262588? What makes it different?

That value above also seems to translate to an error, which is ERROR_GRAPHICS_MCA_INTERNAL_ERROR:

An internal Monitor Configuration API error occurred.

EDIT: The documentation declares such values to be invalid but then goes on to list multiple supposedly invalid values.

edited Jan 4 at 8:48

asked Jan 4 at 7:46

c00000fd

8,3651379232

Since HRESULT is typedef'd as long, the first bit for errors a way to check the result with a generic if (value < 0).

– Giovanni Cerretani
Jan 4 at 8:11

1

@DavidHeffernan: Yes, I could see that. But then there's a quarter of this page full of HRESULT codes that start with 0xC. That's what I'm trying to understand. MS clearly violated that rule.

– c00000fd
Jan 4 at 8:35

1

@DavidHeffernan: I thought I linked to that page in my original post.

– c00000fd
Jan 4 at 8:39

1

The question should explicitly state that the documentation declares such values to be invalid but then goes on to list multiple supposedly invalid values. As it stands, it is not at all obvious that you were aware that the documentation declared such values to be invalid. You made no mention of what it said about bit 30 and for all we know you had not read that part of the documentation. When asking a question, make it clear to the readers the extent of your knowledge and research.

– David Heffernan
Jan 4 at 8:47

1

in case Using NTSTATUS exist significant different between NT_WARNING(Status) and NT_ERROR(Status) (8 vs c) which we take into account in the code (for example copy data and completion. but in case HRESULT we can simply ignore different between 8xxxxxxx and cxxxxxxx

– RbMm
Jan 4 at 13:22

|
show 12 more comments

It's more of a curiosity than anything else. I've been reviewing the HRESULT error codes that many Win32 APIs and Windows components return to signify errors.

If I understand its structure correctly, the most significant bit 31 is the error bit. If it's set, then HRESULT contains an error.

For instance, 0x80004002 is E_NOINTERFACE:

No such interface supported.

But what happens when two of its most significant bits are set as in 0xC0262588? What makes it different?

That value above also seems to translate to an error, which is ERROR_GRAPHICS_MCA_INTERNAL_ERROR:

An internal Monitor Configuration API error occurred.

EDIT: The documentation declares such values to be invalid but then goes on to list multiple supposedly invalid values.

edited Jan 4 at 8:48

asked Jan 4 at 7:46

c00000fd

8,3651379232

Since HRESULT is typedef'd as long, the first bit for errors a way to check the result with a generic if (value < 0).

– Giovanni Cerretani
Jan 4 at 8:11

1

@DavidHeffernan: Yes, I could see that. But then there's a quarter of this page full of HRESULT codes that start with 0xC. That's what I'm trying to understand. MS clearly violated that rule.

– c00000fd
Jan 4 at 8:35

1

@DavidHeffernan: I thought I linked to that page in my original post.

– c00000fd
Jan 4 at 8:39

1

The question should explicitly state that the documentation declares such values to be invalid but then goes on to list multiple supposedly invalid values. As it stands, it is not at all obvious that you were aware that the documentation declared such values to be invalid. You made no mention of what it said about bit 30 and for all we know you had not read that part of the documentation. When asking a question, make it clear to the readers the extent of your knowledge and research.

– David Heffernan
Jan 4 at 8:47

1

in case Using NTSTATUS exist significant different between NT_WARNING(Status) and NT_ERROR(Status) (8 vs c) which we take into account in the code (for example copy data and completion. but in case HRESULT we can simply ignore different between 8xxxxxxx and cxxxxxxx

– RbMm
Jan 4 at 13:22

|
show 12 more comments

It's more of a curiosity than anything else. I've been reviewing the HRESULT error codes that many Win32 APIs and Windows components return to signify errors.

If I understand its structure correctly, the most significant bit 31 is the error bit. If it's set, then HRESULT contains an error.

For instance, 0x80004002 is E_NOINTERFACE:

No such interface supported.

But what happens when two of its most significant bits are set as in 0xC0262588? What makes it different?

That value above also seems to translate to an error, which is ERROR_GRAPHICS_MCA_INTERNAL_ERROR:

An internal Monitor Configuration API error occurred.

EDIT: The documentation declares such values to be invalid but then goes on to list multiple supposedly invalid values.

edited Jan 4 at 8:48

asked Jan 4 at 7:46

c00000fd

8,3651379232

It's more of a curiosity than anything else. I've been reviewing the HRESULT error codes that many Win32 APIs and Windows components return to signify errors.

If I understand its structure correctly, the most significant bit 31 is the error bit. If it's set, then HRESULT contains an error.

For instance, 0x80004002 is E_NOINTERFACE:

No such interface supported.

But what happens when two of its most significant bits are set as in 0xC0262588? What makes it different?

That value above also seems to translate to an error, which is ERROR_GRAPHICS_MCA_INTERNAL_ERROR:

An internal Monitor Configuration API error occurred.

EDIT: The documentation declares such values to be invalid but then goes on to list multiple supposedly invalid values.

c windows winapi hresult

edited Jan 4 at 8:48

asked Jan 4 at 7:46

c00000fd

8,3651379232

edited Jan 4 at 8:48

asked Jan 4 at 7:46

c00000fd

8,3651379232

edited Jan 4 at 8:48

asked Jan 4 at 7:46

c00000fd

8,3651379232

asked Jan 4 at 7:46

c00000fd

8,3651379232

asked Jan 4 at 7:46

c00000fd

8,3651379232

Since HRESULT is typedef'd as long, the first bit for errors a way to check the result with a generic if (value < 0).

– Giovanni Cerretani
Jan 4 at 8:11

1

@DavidHeffernan: Yes, I could see that. But then there's a quarter of this page full of HRESULT codes that start with 0xC. That's what I'm trying to understand. MS clearly violated that rule.

– c00000fd
Jan 4 at 8:35

1

@DavidHeffernan: I thought I linked to that page in my original post.

– c00000fd
Jan 4 at 8:39

1

The question should explicitly state that the documentation declares such values to be invalid but then goes on to list multiple supposedly invalid values. As it stands, it is not at all obvious that you were aware that the documentation declared such values to be invalid. You made no mention of what it said about bit 30 and for all we know you had not read that part of the documentation. When asking a question, make it clear to the readers the extent of your knowledge and research.

– David Heffernan
Jan 4 at 8:47

1

in case Using NTSTATUS exist significant different between NT_WARNING(Status) and NT_ERROR(Status) (8 vs c) which we take into account in the code (for example copy data and completion. but in case HRESULT we can simply ignore different between 8xxxxxxx and cxxxxxxx

– RbMm
Jan 4 at 13:22

|
show 12 more comments

Since HRESULT is typedef'd as long, the first bit for errors a way to check the result with a generic if (value < 0).

– Giovanni Cerretani
Jan 4 at 8:11

1

@DavidHeffernan: Yes, I could see that. But then there's a quarter of this page full of HRESULT codes that start with 0xC. That's what I'm trying to understand. MS clearly violated that rule.

– c00000fd
Jan 4 at 8:35

1

@DavidHeffernan: I thought I linked to that page in my original post.

– c00000fd
Jan 4 at 8:39

1

The question should explicitly state that the documentation declares such values to be invalid but then goes on to list multiple supposedly invalid values. As it stands, it is not at all obvious that you were aware that the documentation declared such values to be invalid. You made no mention of what it said about bit 30 and for all we know you had not read that part of the documentation. When asking a question, make it clear to the readers the extent of your knowledge and research.

– David Heffernan
Jan 4 at 8:47

1

in case Using NTSTATUS exist significant different between NT_WARNING(Status) and NT_ERROR(Status) (8 vs c) which we take into account in the code (for example copy data and completion. but in case HRESULT we can simply ignore different between 8xxxxxxx and cxxxxxxx

– RbMm
Jan 4 at 13:22

Since HRESULT is typedef'd as long, the first bit for errors a way to check the result with a generic if (value < 0).

– Giovanni Cerretani
Jan 4 at 8:11

@DavidHeffernan: Yes, I could see that. But then there's a quarter of this page full of HRESULT codes that start with 0xC. That's what I'm trying to understand. MS clearly violated that rule.

– c00000fd
Jan 4 at 8:35

@DavidHeffernan: I thought I linked to that page in my original post.

– c00000fd
Jan 4 at 8:39

The question should explicitly state that the documentation declares such values to be invalid but then goes on to list multiple supposedly invalid values. As it stands, it is not at all obvious that you were aware that the documentation declared such values to be invalid. You made no mention of what it said about bit 30 and for all we know you had not read that part of the documentation. When asking a question, make it clear to the readers the extent of your knowledge and research.

– David Heffernan
Jan 4 at 8:47

in case Using NTSTATUS exist significant different between NT_WARNING(Status) and NT_ERROR(Status) (8 vs c) which we take into account in the code (for example copy data and completion. but in case HRESULT we can simply ignore different between 8xxxxxxx and cxxxxxxx

– RbMm
Jan 4 at 13:22

|
show 12 more comments

1 Answer
1

active

oldest

votes

From the Structures of HRESULT definition, 0x8 and 0xC is different at "R" bit and if the N bit is set, this bit is defined by the NTSTATUS numbering space. In NTSTATUS definition, 0x8 indicate STATUS_SEVERITY_WARNING and 0xC indicate STATUS_SEVERITY_ERROR.

enter image description here

Ref: "[MS-ERREF]: Windows Error Codes"

answered Jan 7 at 9:55

Rita Han - MSFT

5,2561313

The question is about why there are many HRESULT values defined with a two-bit severity code in shared/winerror.h, um/nserror.h, um/mferror.h, and winrt/dlnaerror.h. In many cases, it's simply that the same set of codes are made available as NTSTATUS and (improper) HRESULT values by defining the same facility code in both domains and storing the same messages for the status codes in both ntdll.dll.mui and kernelbase.dll.mui. But other HRESULT-only facilities also have these strictly improper severity codes. See my comments on the question itself for examples.

– eryksun
Jan 7 at 10:12

This documentation looks weird, because it excludes the value 0xC0 in the MSB: if N is zero, R must be zero. But such values exist as already the question and some comments show. Further the bit number line is in wrong order. MSB is left.

– harper
Jan 7 at 12:49

@harper yes, I agree with you about this document and I am researching and confirming internal. As for bit order, there is such sentence "Values are 32 bit and are laid out as follows. The following diagram is independent of endianness; that is, the diagram is shown in host byte order and merely shows the layout of the numbering space." Does it clear your confusion?

– Rita Han - MSFT
Jan 8 at 7:16

@eryksun In the document I refered to it says that it is possible to map an NTSTATUS value to an equivalent HRESULT value. And I search the oxC codes in HRESULT, for example, AUDITING_DISABLED(The specified event is currently not being audited.) you will see the similar one listed in NTSTATUS. But I don't know what's the map rules. Can this explain what you have found in header files?

– Rita Han - MSFT
Jan 8 at 7:27

STATUS_AUDITING_DISABLED and ERROR_AUDITING_DISABLED are related in practice, but the codes have nothing to do with each other (i.e. 0xC0000356 vs 0xC0090001). The former is in the NTSTATUS System facility (0x000), and the latter is in the HRESULT Security facility (0x009). We can flag the former with the NT facility bit (i.e. 0xC0000356 | 0x10000000 == 0xD0000356) if returned as an HRESULT. Users should clear the NT bit and look up the message for 0xC0000356 in ntdll.dll. OTOH, 0xC0090001 is an HRESULT, not an NTSTATUS code, and its message is in kernelbase.dll, not ntdll.dll.

– eryksun
Jan 8 at 9:59

|
show 3 more comments

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54034910%2fwhat-is-the-difference-between-hresult-error-codes-that-start-with-0x8-and-with%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

enter image description here

Ref: "[MS-ERREF]: Windows Error Codes"

answered Jan 7 at 9:55

Rita Han - MSFT

5,2561313

The question is about why there are many HRESULT values defined with a two-bit severity code in shared/winerror.h, um/nserror.h, um/mferror.h, and winrt/dlnaerror.h. In many cases, it's simply that the same set of codes are made available as NTSTATUS and (improper) HRESULT values by defining the same facility code in both domains and storing the same messages for the status codes in both ntdll.dll.mui and kernelbase.dll.mui. But other HRESULT-only facilities also have these strictly improper severity codes. See my comments on the question itself for examples.

– eryksun
Jan 7 at 10:12

This documentation looks weird, because it excludes the value 0xC0 in the MSB: if N is zero, R must be zero. But such values exist as already the question and some comments show. Further the bit number line is in wrong order. MSB is left.

– harper
Jan 7 at 12:49

@harper yes, I agree with you about this document and I am researching and confirming internal. As for bit order, there is such sentence "Values are 32 bit and are laid out as follows. The following diagram is independent of endianness; that is, the diagram is shown in host byte order and merely shows the layout of the numbering space." Does it clear your confusion?

– Rita Han - MSFT
Jan 8 at 7:16

@eryksun In the document I refered to it says that it is possible to map an NTSTATUS value to an equivalent HRESULT value. And I search the oxC codes in HRESULT, for example, AUDITING_DISABLED(The specified event is currently not being audited.) you will see the similar one listed in NTSTATUS. But I don't know what's the map rules. Can this explain what you have found in header files?

– Rita Han - MSFT
Jan 8 at 7:27

STATUS_AUDITING_DISABLED and ERROR_AUDITING_DISABLED are related in practice, but the codes have nothing to do with each other (i.e. 0xC0000356 vs 0xC0090001). The former is in the NTSTATUS System facility (0x000), and the latter is in the HRESULT Security facility (0x009). We can flag the former with the NT facility bit (i.e. 0xC0000356 | 0x10000000 == 0xD0000356) if returned as an HRESULT. Users should clear the NT bit and look up the message for 0xC0000356 in ntdll.dll. OTOH, 0xC0090001 is an HRESULT, not an NTSTATUS code, and its message is in kernelbase.dll, not ntdll.dll.

– eryksun
Jan 8 at 9:59

|
show 3 more comments

enter image description here

Ref: "[MS-ERREF]: Windows Error Codes"

answered Jan 7 at 9:55

Rita Han - MSFT

5,2561313

The question is about why there are many HRESULT values defined with a two-bit severity code in shared/winerror.h, um/nserror.h, um/mferror.h, and winrt/dlnaerror.h. In many cases, it's simply that the same set of codes are made available as NTSTATUS and (improper) HRESULT values by defining the same facility code in both domains and storing the same messages for the status codes in both ntdll.dll.mui and kernelbase.dll.mui. But other HRESULT-only facilities also have these strictly improper severity codes. See my comments on the question itself for examples.

– eryksun
Jan 7 at 10:12

This documentation looks weird, because it excludes the value 0xC0 in the MSB: if N is zero, R must be zero. But such values exist as already the question and some comments show. Further the bit number line is in wrong order. MSB is left.

– harper
Jan 7 at 12:49

@harper yes, I agree with you about this document and I am researching and confirming internal. As for bit order, there is such sentence "Values are 32 bit and are laid out as follows. The following diagram is independent of endianness; that is, the diagram is shown in host byte order and merely shows the layout of the numbering space." Does it clear your confusion?

– Rita Han - MSFT
Jan 8 at 7:16

@eryksun In the document I refered to it says that it is possible to map an NTSTATUS value to an equivalent HRESULT value. And I search the oxC codes in HRESULT, for example, AUDITING_DISABLED(The specified event is currently not being audited.) you will see the similar one listed in NTSTATUS. But I don't know what's the map rules. Can this explain what you have found in header files?

– Rita Han - MSFT
Jan 8 at 7:27

STATUS_AUDITING_DISABLED and ERROR_AUDITING_DISABLED are related in practice, but the codes have nothing to do with each other (i.e. 0xC0000356 vs 0xC0090001). The former is in the NTSTATUS System facility (0x000), and the latter is in the HRESULT Security facility (0x009). We can flag the former with the NT facility bit (i.e. 0xC0000356 | 0x10000000 == 0xD0000356) if returned as an HRESULT. Users should clear the NT bit and look up the message for 0xC0000356 in ntdll.dll. OTOH, 0xC0090001 is an HRESULT, not an NTSTATUS code, and its message is in kernelbase.dll, not ntdll.dll.

– eryksun
Jan 8 at 9:59

|
show 3 more comments

enter image description here

Ref: "[MS-ERREF]: Windows Error Codes"

answered Jan 7 at 9:55

Rita Han - MSFT

5,2561313

enter image description here

Ref: "[MS-ERREF]: Windows Error Codes"

answered Jan 7 at 9:55

Rita Han - MSFT

5,2561313

answered Jan 7 at 9:55

Rita Han - MSFT

5,2561313

answered Jan 7 at 9:55

Rita Han - MSFT

5,2561313

answered Jan 7 at 9:55

Rita Han - MSFT

5,2561313

The question is about why there are many HRESULT values defined with a two-bit severity code in shared/winerror.h, um/nserror.h, um/mferror.h, and winrt/dlnaerror.h. In many cases, it's simply that the same set of codes are made available as NTSTATUS and (improper) HRESULT values by defining the same facility code in both domains and storing the same messages for the status codes in both ntdll.dll.mui and kernelbase.dll.mui. But other HRESULT-only facilities also have these strictly improper severity codes. See my comments on the question itself for examples.

– eryksun
Jan 7 at 10:12

This documentation looks weird, because it excludes the value 0xC0 in the MSB: if N is zero, R must be zero. But such values exist as already the question and some comments show. Further the bit number line is in wrong order. MSB is left.

– harper
Jan 7 at 12:49

@harper yes, I agree with you about this document and I am researching and confirming internal. As for bit order, there is such sentence "Values are 32 bit and are laid out as follows. The following diagram is independent of endianness; that is, the diagram is shown in host byte order and merely shows the layout of the numbering space." Does it clear your confusion?

– Rita Han - MSFT
Jan 8 at 7:16

@eryksun In the document I refered to it says that it is possible to map an NTSTATUS value to an equivalent HRESULT value. And I search the oxC codes in HRESULT, for example, AUDITING_DISABLED(The specified event is currently not being audited.) you will see the similar one listed in NTSTATUS. But I don't know what's the map rules. Can this explain what you have found in header files?

– Rita Han - MSFT
Jan 8 at 7:27

STATUS_AUDITING_DISABLED and ERROR_AUDITING_DISABLED are related in practice, but the codes have nothing to do with each other (i.e. 0xC0000356 vs 0xC0090001). The former is in the NTSTATUS System facility (0x000), and the latter is in the HRESULT Security facility (0x009). We can flag the former with the NT facility bit (i.e. 0xC0000356 | 0x10000000 == 0xD0000356) if returned as an HRESULT. Users should clear the NT bit and look up the message for 0xC0000356 in ntdll.dll. OTOH, 0xC0090001 is an HRESULT, not an NTSTATUS code, and its message is in kernelbase.dll, not ntdll.dll.

– eryksun
Jan 8 at 9:59

|
show 3 more comments

The question is about why there are many HRESULT values defined with a two-bit severity code in shared/winerror.h, um/nserror.h, um/mferror.h, and winrt/dlnaerror.h. In many cases, it's simply that the same set of codes are made available as NTSTATUS and (improper) HRESULT values by defining the same facility code in both domains and storing the same messages for the status codes in both ntdll.dll.mui and kernelbase.dll.mui. But other HRESULT-only facilities also have these strictly improper severity codes. See my comments on the question itself for examples.

– eryksun
Jan 7 at 10:12

This documentation looks weird, because it excludes the value 0xC0 in the MSB: if N is zero, R must be zero. But such values exist as already the question and some comments show. Further the bit number line is in wrong order. MSB is left.

– harper
Jan 7 at 12:49

@harper yes, I agree with you about this document and I am researching and confirming internal. As for bit order, there is such sentence "Values are 32 bit and are laid out as follows. The following diagram is independent of endianness; that is, the diagram is shown in host byte order and merely shows the layout of the numbering space." Does it clear your confusion?

– Rita Han - MSFT
Jan 8 at 7:16

@eryksun In the document I refered to it says that it is possible to map an NTSTATUS value to an equivalent HRESULT value. And I search the oxC codes in HRESULT, for example, AUDITING_DISABLED(The specified event is currently not being audited.) you will see the similar one listed in NTSTATUS. But I don't know what's the map rules. Can this explain what you have found in header files?

– Rita Han - MSFT
Jan 8 at 7:27

STATUS_AUDITING_DISABLED and ERROR_AUDITING_DISABLED are related in practice, but the codes have nothing to do with each other (i.e. 0xC0000356 vs 0xC0090001). The former is in the NTSTATUS System facility (0x000), and the latter is in the HRESULT Security facility (0x009). We can flag the former with the NT facility bit (i.e. 0xC0000356 | 0x10000000 == 0xD0000356) if returned as an HRESULT. Users should clear the NT bit and look up the message for 0xC0000356 in ntdll.dll. OTOH, 0xC0090001 is an HRESULT, not an NTSTATUS code, and its message is in kernelbase.dll, not ntdll.dll.

– eryksun
Jan 8 at 9:59

The question is about why there are many HRESULT values defined with a two-bit severity code in shared/winerror.h, um/nserror.h, um/mferror.h, and winrt/dlnaerror.h. In many cases, it's simply that the same set of codes are made available as NTSTATUS and (improper) HRESULT values by defining the same facility code in both domains and storing the same messages for the status codes in both ntdll.dll.mui and kernelbase.dll.mui. But other HRESULT-only facilities also have these strictly improper severity codes. See my comments on the question itself for examples.

– eryksun
Jan 7 at 10:12

This documentation looks weird, because it excludes the value 0xC0 in the MSB: if N is zero, R must be zero. But such values exist as already the question and some comments show. Further the bit number line is in wrong order. MSB is left.

– harper
Jan 7 at 12:49

@harper yes, I agree with you about this document and I am researching and confirming internal. As for bit order, there is such sentence "Values are 32 bit and are laid out as follows. The following diagram is independent of endianness; that is, the diagram is shown in host byte order and merely shows the layout of the numbering space." Does it clear your confusion?

– Rita Han - MSFT
Jan 8 at 7:16

@eryksun In the document I refered to it says that it is possible to map an NTSTATUS value to an equivalent HRESULT value. And I search the oxC codes in HRESULT, for example, AUDITING_DISABLED(The specified event is currently not being audited.) you will see the similar one listed in NTSTATUS. But I don't know what's the map rules. Can this explain what you have found in header files?

– Rita Han - MSFT
Jan 8 at 7:27

STATUS_AUDITING_DISABLED and ERROR_AUDITING_DISABLED are related in practice, but the codes have nothing to do with each other (i.e. 0xC0000356 vs 0xC0090001). The former is in the NTSTATUS System facility (0x000), and the latter is in the HRESULT Security facility (0x009). We can flag the former with the NT facility bit (i.e. 0xC0000356 | 0x10000000 == 0xD0000356) if returned as an HRESULT. Users should clear the NT bit and look up the message for 0xC0000356 in ntdll.dll. OTOH, 0xC0090001 is an HRESULT, not an NTSTATUS code, and its message is in kernelbase.dll, not ntdll.dll.

– eryksun
Jan 8 at 9:59

|
show 3 more comments

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Bdtjtk