<div class="content"><p> </p><p>The IRPCAsyncNotify_CloseChannel method sends a final <span><a href="4751a17a-76f3-4a7a-aef3-fdfc5d1bc7a5#gt_115e9f9c-314e-49fc-977d-238daf619828" data-linktype="relative-path">response</a></span>
on the <span><a href="4751a17a-76f3-4a7a-aef3-fdfc5d1bc7a5#gt_31f349c9-3af0-4057-9d90-5ecb958398a5" data-linktype="relative-path">notification channel</a></span>
and closes it. This method MUST NOT be used with <span><a href="4751a17a-76f3-4a7a-aef3-fdfc5d1bc7a5#gt_d203482a-15ef-4528-9064-68b0f2e0c5fa" data-linktype="relative-path">unidirectional communication
mode</a></span>.</p><dl>
<dd>
<div><pre> HRESULT IRPCAsyncNotify_CloseChannel(
   [in, out] PNOTIFYOBJECT* pChannel,
   [in] PrintAsyncNotificationType* pInNotificationType,
   [in] unsigned long InSize,
   [in, size_is(InSize), unique] byte* pReason
 );
</pre></div>
</dd></dl><p><b>pChannel: </b>MUST be a pointer to a notification
channel that MUST NOT be closed or zero and that MUST have been returned by the
server in the <i>ppChannelCtxt</i> output parameter of a prior call to <span><a href="0851fada-b2ca-441f-835a-2503d3862a1f" data-linktype="relative-path">IRPCAsyncNotify_GetNewChannel</a></span>.
Upon receipt, the server MUST set the <b>pChannel</b> value to NULL.</p><p><b>pInNotificationType: </b>MUST be a pointer to a <span><a href="89ef806f-96ee-4178-9f36-3e1420820a4f" data-linktype="relative-path">PrintAsyncNotificationType</a></span>
value. If the client needs to close the notification channels without sending a
final response, then this value SHOULD point to <b>NOTIFICATION_RELEASE</b>. In
all other cases, this value MUST point to the <span><a href="4751a17a-76f3-4a7a-aef3-fdfc5d1bc7a5#gt_928ce1b5-ae98-4601-b500-48cb24b2affc" data-linktype="relative-path">notification type identifier</a></span>
of the <span><a href="4751a17a-76f3-4a7a-aef3-fdfc5d1bc7a5#gt_ad9bb1cf-c546-4d8a-8caa-09856386eae0" data-linktype="relative-path">notification type</a></span>
for which the client has registered.</p><p><b>InSize: </b>The server SHOULD impose an upper
limit on this value that is smaller than the maximum unsigned 32-bit integer.
That limit SHOULD be 0x00A00000. If the client exceeds the server-imposed
limit, the server MUST return an error result.</p><p>If <b>pInNotificationType</b> is <b>NOTIFICATION_RELEASE</b>,
then InSize SHOULD be 0x00000000.</p><p><b>pReason: </b>MUST be a pointer to a sequence of
bytes conveying final client-to-server response data. The number of bytes MUST
be provided in the <i>InSize</i> parameter. If InSize is not 0x00000000, then
pReason MUST NOT be NULL.</p><p>If <b>pInNotificationType</b> is <b>NOTIFICATION_RELEASE</b>,
then the client SHOULD provide zero bytes of response data and the server MUST
ignore any response data pointed to by <b>pReason</b>. If <b>pInNotificationType</b>
is not <b>NOTIFICATION_RELEASE</b>, then the response format MUST conform to
the requirements of the notification channel&#39;s notification type and those
notification type requirements determine whether or not a zero-byte response is
acceptable. </p><p><b>Return Values: </b>This method MUST return zero or
an <span><a href="4751a17a-76f3-4a7a-aef3-fdfc5d1bc7a5#gt_799103ab-b3cb-4eab-8c55-322821b2b235" data-linktype="relative-path">HRESULT</a></span>
success value (<span><a href="../ms-erref/1bc92ddf-b79e-413c-bbaa-99a5281a6c90" data-linktype="relative-path">[MS-ERREF]</a></span>
section <span><a href="../ms-erref/705fb797-2175-4a90-b5a3-3918024b10b8" data-linktype="relative-path">2.1.1</a></span>)
to indicate success, or an HRESULT error value to indicate failure. </p><p>Protocol-specific success values are defined in the
following table.</p><table><thead>
  <tr>
   <th>
   <p>Return value</p>
   </th>
   <th>
   <p>Description</p>
   </th>
  </tr>
 </thead><tbody><tr>
  <td>
  <p>0x00040010</p>
  </td>
  <td>
  <p>Another client has acquired the channel.</p>
  </td>
 </tr></tbody></table><p>Protocol-specific error values are defined in the following
table. The client MUST consider all error return values fatal and report them
to the higher-level caller.</p><table><thead>
  <tr>
   <th>
   <p>Return value</p>
   </th>
   <th>
   <p>Description</p>
   </th>
  </tr>
 </thead><tbody><tr>
  <td>
  <p>0x80040012</p>
  </td>
  <td>
  <p>The response exceeds the maximum size allowed by the
  server.</p>
  </td>
 </tr><tr>
  <td>
  <p>0x80040014</p>
  </td>
  <td>
  <p>The notification type identifier is different from the
  notification type of the notification channel.</p>
  </td>
 </tr><tr>
  <td>
  <p>0x8007000E</p>
  </td>
  <td>
  <p>The server does not have enough memory to complete the
  request.</p>
  </td>
 </tr></tbody></table><p><b>Exceptions Thrown:</b> No exceptions are thrown
beyond those thrown by the underlying RPC protocol <span><a href="../ms-rpce/290c38b1-92fe-4229-91e6-4fc376610c15" data-linktype="relative-path">[MS-RPCE]</a></span>.</p><p>If a client call to <span><a href="8c4aab2d-5dfe-469d-a9e3-003869921e45" data-linktype="relative-path">IRPCAsyncNotify_GetNotificationSendResponse</a></span>
is blocked on the server, waiting for a notification to become available on a
notification channel, then the server MUST process a client call to this method
on the same notification channel without waiting for a notification.</p><p>A client MUST NOT call IRPCAsyncNotify_CloseChannel
following a prior successful return from
IRPCAsyncNotify_GetNotificationSendResponse with a NULL value of <i>pChannel</i>
parameter or following a prior successful return from
IRPCAsyncNotify_CloseChannel.<a id="Appendix_A_Target_11"></a><a aria-label="Product behavior note 11" href="cdec7a7c-2b2c-4b81-a40a-b12d69f880ee#Appendix_A_11" data-linktype="relative-path">&lt;11&gt;</a></p></div>