3.1.4.2.36 ApiDeleteKey (Opnum 35)

(Protocol Version 3) In response to an ApiDeleteKey request from the client, for a successful operation, the server MUST delete the registry key that is specified by the lpSubKey parameter in the client request.

The server MUST accept an ApiDeleteKey request only if its protocol server state is read/write, as specified in section 3.1.1.

The server MUST require that the client have a security access level of "All" (section 3.1.4).

 error_status_t ApiDeleteKey(
   [in] HKEY_RPC hKey,
   [in, string] LPCWSTR lpSubKey,
   [out] error_status_t *rpc_status
 );

hKey: The HKEY_RPC context handle for a key that was previously obtained by a call to ApiGetRootKey, ApiCreateKey, or ApiOpenKey.

lpSubKey: A null-terminated Unicode string that specifies the name of the subkey to be deleted. The lpSubKey parameter MUST indicate a subkey that is a child of the key that is identified by hKey, does not begin with the "\" character, and is not NULL. The server MUST fail the request with ERROR_ACCESS_DENIED (0x00000005) if lpSubKey has one or more subkeys.

rpc_status: A 32-bit integer used to indicate success or failure. The RPC runtime MUST indicate, by writing to this parameter, whether it succeeded in executing this method on the server. The encoding of the value passed in this parameter MUST conform to encoding for comm_status and fault_status, as specified in Appendix E of [C706].

Return Values: The method MUST return the following error codes for the specified conditions.

Return value/code	Description
0x00000000 ERROR_SUCCESS	Success.
0x00000005 ERROR_ACCESS_DENIED	The lpSubKey parameter has one or more subkeys. The client does not have an access level of "All", as specified in section 3.1.4.
0x00000006 ERROR_INVALID_HANDLE	The data that is pointed to by the hKey parameter does not represent a valid HKEY_RPC context handle.

For any other condition, this method MUST return a value that is not one of the values listed in the preceding table. The client MUST behave in one consistent, identical manner for all values that are not listed in the preceding table. The client SHOULD treat errors specified in 3.2.4.6 as recoverable errors and initiate the reconnect procedure as specified in section 3.2.4.6.