Unknown HRESULT (0x8006FC24) from DirectInput

D619d95cddb1edb227f51ef539d15cdc
0
Nautilus 103 Jun 10, 2013 at 13:35

A call to IDirectInputDevice7::GetDeviceState() is failing unexpectedly. The HRESULT code returned is being 2147941412 (0x8006FC24), which maps to nothing known. According to this Microsoft page the Facility code of the HRESULT (0x8006FC24) is undefined. How can I understand what’s wrong?

Thanks in advance.

4 Replies

Please log in or register to post a reply.

B5262118b588a5a420230bfbef4a2cdf
0
Stainless 151 Jun 10, 2013 at 16:27

I think this maps to ….

4 = customer bit (not a Microsoft error)

you are reading it the wrong way around

S = 0
R = 0
C = 1
N = 0 (== digit 4)

X = 0
The next 11 bits = 0x3FC, so the facility is undefined as you said.

However since the S bit is zero, it looks like the code does not represent an error.

Somewhere in the back of my memory that facility is something to do with OSDSetupHook, something to do with installing a duff device driver

D619d95cddb1edb227f51ef539d15cdc
0
Nautilus 103 Jun 11, 2013 at 01:03

No, I disagree.
This is from <winerror.h>

//
//  Values are 32 bit values layed out as follows:
//
//   3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
//   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
//  +---+-+-+-----------------------+-------------------------------+
//  |Sev|C|R|    Facility         |            Code         |
//  +---+-+-+-----------------------+-------------------------------+
//
//  where
//
//    Sev - is the severity code
//
//        00 - Success
//        01 - Informational
//        10 - Warning
//        11 - Error
//
//    C - is the Customer code flag
//
//    R - is a reserved bit
//
//    Facility - is the facility code
//
//    Code - is the facility's status code
//
//
// Define the facility codes
//
#define FACILITY_WINDOWSUPDATE         36
#define FACILITY_WINDOWS_CE           24
#define FACILITY_WINDOWS                 8
#define FACILITY_URT                     19
#define FACILITY_UMI                     22
#define FACILITY_SXS                     23
#define FACILITY_STORAGE                 3
#define FACILITY_STATE_MANAGEMENT       34
#define FACILITY_SSPI                   9
#define FACILITY_SCARD                 16
#define FACILITY_SETUPAPI               15
#define FACILITY_SECURITY               9
#define FACILITY_RPC                     1
#define FACILITY_WIN32                 7
#define FACILITY_CONTROL                 10
#define FACILITY_NULL                   0
#define FACILITY_METADIRECTORY         35
#define FACILITY_MSMQ                   14
#define FACILITY_MEDIASERVER             13
#define FACILITY_INTERNET               12
#define FACILITY_ITF                     4
#define FACILITY_HTTP                   25
#define FACILITY_DPLAY                 21
#define FACILITY_DISPATCH               2
#define FACILITY_DIRECTORYSERVICE       37
#define FACILITY_CONFIGURATION         33
#define FACILITY_COMPLUS                 17
#define FACILITY_CERT                   11
#define FACILITY_BACKGROUNDCOPY       32
#define FACILITY_ACS                     20
#define FACILITY_AAF                     18

(while at it, notice the absence of Facility 6)

And this is from the 1st paragraph of the 2.1 HRESULT webpage I linked:

The HRESULT numbering space is vendor-extensible. Vendors can supply their own values for this field, as long as the C bit (0x20000000) is set, indicating it is a customer code.

Clearly, the C bit is bit_29 (or the 30th bit from the right – little endian).

Let’s make a practical example with the #definition of DIERR_INPUTLOST from <dinput.h>:

/*
* Access to the device has been lost.  It must be re-acquired.
*/
#define DIERR_INPUTLOST              \
    MAKE_HRESULT(SEVERITY_ERROR, FACILITY_WIN32, ERROR_READ_FAULT)

The MAKE_HRESULT macro from <winerror.h>:

//
// Create an HRESULT value from component pieces
//

#define MAKE_HRESULT(sev,fac,code) \
    ((HRESULT) (((unsigned long)(sev)<<31) | ((unsigned long)(fac)<<16) | ((unsigned long)(code))) )

With the macros SEVERITY_ERROR, FACILITY_WIN32, and ERROR_READ_FAULT expanding to 1, 7 and 30L respectively (all from <winerror.h>), we have that:

DIERR_INPUTLOST = (1 << 31) | (7 << 16) | (30L)
DIERR_INPUTLOST = 0x8007001E
DIERR_INPUTLOST = 2147942430

In this case Facility is 7, which is “FACILITY_WIN32” according to the 2.1 HRESULT page as well.
Therefore the Facility field within the HRESULT I’m getting from DirectInput is a genuine 6 – unless the error code is longer than 16 bits (which is out of the rules, even though the macro won’t see to clamp it) so making the true Facility either 0, 2 or 4. In any case this HRESULT value is undocumented.

B5262118b588a5a420230bfbef4a2cdf
0
Stainless 151 Jun 11, 2013 at 07:59

Great so Microsoft’s documentation for it’s own OS is wrong.

Why am I not suprised.

Have you tried DXGetErrorString8or DXGetErrorDescription8

D619d95cddb1edb227f51ef539d15cdc
0
Nautilus 103 Jun 12, 2013 at 13:12

No luck :(

DXGetErrorString (0x8006FC24); returned “Unknown”
DXGetErrorDescription (0x8006FC24); returned “n/a”

But it was worth to try.
I have also tried many an error lookup utility, starting with the one that comes with VS. All negative.
Why there’s no reference of this error anywhere? I can’t be the first to get it. My direct input setup leaves no room for creativity. Maybe the HWND I was feeding to IDirectInputDevice7::SetCooperativeLevel() wasn’t good. So I changed that: to NULL, to the Foreground window, to any of the windows belonging to the process… it’s always 8006FC24.
I want to believe: gremlins do exist!

If I repeat the test with DirectInput8 it all works as per the documentation. I’ll switch to DI8 and move on.