<div class="content" name="R_WinsDoScavenging" uuid="b8437539-dd6f-4857-94b2-f7dfe4370b3c"><p>The R_WinsDoScavenging method queues a <a href="a83205a2-23e2-41bb-84e1-4d968aaae4e8#gt_345c3de7-adfa-4386-9ba5-f5f572af489c" data-linktype="relative-path">scavenging</a> request on the <a href="a83205a2-23e2-41bb-84e1-4d968aaae4e8#gt_cb0d3fc4-7e24-49af-82c4-91a35bca857f" data-linktype="relative-path">target WINS server</a>.</p><dl>
<dd>
<div><pre> DWORD R_WinsDoScavenging(
   [in] handle_t ServerHdl
 );
</pre></div>
</dd></dl><p><b>ServerHdl: </b>An <a href="a83205a2-23e2-41bb-84e1-4d968aaae4e8#gt_8a7f6700-8311-45bc-af10-82e10accd331" data-linktype="relative-path">RPC</a> binding over IP
address/HostName to the <a href="a83205a2-23e2-41bb-84e1-4d968aaae4e8#gt_bafb050b-b593-4517-8093-f721bd2378ac" data-linktype="relative-path">WINS</a>
server. RPC uses this binding internally to determine which WINS server the
call is directed to.</p><p><b>Return Values: </b>A 32 bit unsigned integer that
indicates the return status. A return value of ERROR_SUCCESS (0x00000000)
indicates that the operation completed successfully. A nonzero return value is
a Win32 error code, as specified in <a href="../ms-erref/1bc92ddf-b79e-413c-bbaa-99a5281a6c90" data-linktype="relative-path">[MS-ERREF]</a>.
The following Win32 error codes can be returned:</p><dl>
<dd>
<table><thead>
  <tr>
   <th>
   <p>Return value/code</p>
   </th>
   <th>
   <p>Description</p>
   </th>
  </tr>
 </thead><tbody><tr>
  <td>0x00000000 ERROR_SUCCESS</td>
  <td>The call was successful.</td>
 </tr><tr>
  <td>0x00000005 ERROR_ACCESS_DENIED</td>
  <td>The caller doesn&#39;t have sufficient permissions.</td>
 </tr></tbody></table>
</dd></dl><p><b>Exceptions Thrown:</b> No exceptions are thrown beyond
those thrown by the underlying RPC protocol <a href="../ms-rpce/290c38b1-92fe-4229-91e6-4fc376610c15" data-linktype="relative-path">[MS-RPCE]</a>.</p><p><b>Processing and Response Requirements:</b></p><p>When R_WinsDoScanvenging is called, the server returns
immediately without waiting for scavenging to start. The server just queues a
request for the scavenging operation, and the internal state and configuration
of the WINS server determine whether or not the scavenging occurs.
Hence,callers to R_WinsDoScanvenging SHOULD NOT treat a return code of
ERROR_SUCCESS as indicating a successful scavenging operation. Instead, callers
SHOULD rely on WINS event logs to determine whether or not the scavenging
operation succeeded. The following table lists the events that indicate the
status of scavenging.</p><table><thead>
  <tr>
   <th>
   <p>Event ID</p>
   </th>
   <th>
   <p>Event Name</p>
   </th>
   <th>
   <p>Event Description</p>
   </th>
  </tr>
 </thead><tbody><tr>
  <td colspan="3">Informational events</td>
 </tr><tr>
  <td>4143</td>
  <td>WINS_EVT_SCV_RECS</td>
  <td>WINS scavenged its records in the WINS database. The number of records scavenged is given in the data section.</td>
 </tr><tr>
  <td>4144</td>
  <td>WINS_EVT_SCV_RPLTOMB</td>
  <td>WINS scavenged replica tombstones in the WINS database. The number of records scavenged is given in the data section.</td>
 </tr><tr>
  <td>4247</td>
  <td>WINS_EVT_SCV_EXC</td>
  <td>The WINS Scavenger thread encountered an error.</td>
 </tr><tr>
  <td>4250</td>
  <td>WINS_EVT_SCV_ERR</td>
  <td>The WINS Scavenger thread could not scavenge a record. This record will be ignored. The Scavenger will continue to the next available record. Check the application log for the Exchange component, ESENT.</td>
 </tr><tr>
  <td>4269</td>
  <td>WINS_EVT_UNABLE_TO_CHG_PRIORITY</td>
  <td>The Scavenger thread was unable to change its priority level.</td>
 </tr><tr>
  <td>4288</td>
  <td>WINS_EVT_CLEANUP_OWNADDTBL_EXC</td>
  <td>The Scavenger thread encountered an error while cleaning up the owner-address table. It will try again after the Verify interval has elapsed.</td>
 </tr><tr>
  <td>4328</td>
  <td>WINS_EVT_ADMIN_SCVENGING_INITIATED</td>
  <td>Administrator &#39;%1&#39; has initiated a scavenging operation.</td>
 </tr><tr>
  <td>4329</td>
  <td>WINS_EVT_SCVENGING_STARTED</td>
  <td>The WINS server has started a scavenging operation.</td>
 </tr><tr>
  <td>4330</td>
  <td>WINS_EVT_SCVENGING_COMPLETED</td>
  <td>The WINS server has completed the scavenging operation.</td>
 </tr><tr>
  <td>5001</td>
  <td>WINS_EVT_SCV_RANGE</td>
  <td>WINS is scavenging the locally owned records from the database. The version number range that is scavenged is given in the data section, in the second to fifth words, in the order: from_version_number (low word, high word) to_version_number (low word, high word).</td>
 </tr><tr>
  <td>5002</td>
  <td>WINS_EVT_SCV_CHUNK</td>
  <td>WINS is scavenging a chunk of N records in the version number range from X to Y. N, X and Y (low word, high word for version numbers) are given in the second to sixth words in the data section.</td>
 </tr><tr>
  <td colspan="3">Warning events</td>
 </tr><tr>
  <td>4150</td>
  <td>WINS_EVT_ADJ_TIME_INTVL_R</td>
  <td>WINS adjusted the scavenging-related time interval, %1, so that it is compatible with the replication time intervals. The adjusted value for this scavenging parameter is given in the data section (second DWORD). This value was computed by WINS using an algorithm that MAY use the maximum replication time interval specified. The current value achieves a good balance between consistency of databases across the network of WINS servers and the performance of the WINS servers.</td>
 </tr><tr>
  <td>4151</td>
  <td>WINS_EVT_ADJ_TIME_INTVL</td>
  <td>WINS adjusted the scavenging-related time interval, %1. The adjusted value for this scavenging parameter is given in the data section (second DWORD). This value was computed by WINS using an algorithm that tries to achieve a good balance between consistency of databases across the network of WINS servers and the performance of the WINS servers.</td>
 </tr><tr>
  <td>4153</td>
  <td>WINS_EVT_UNABLE_TO_VERIFY</td>
  <td>The Scavenger thread found active replicas that needed to be verified with the owning WINS server because they were older than the verify time interval. The table of owner-to-address mappings indicated the WINS was not active.</td>
 </tr><tr>
  <td>4164</td>
  <td>WINS_EVT_FORCE_SCV_R_T</td>
  <td>WINS was forced to scavenge replica tombstones of a WINS. The person with administrative rights on the computer forced the scavenging by using the winscl.exe. WINS does not scavenge replica tombstones unless they have timed out and WINS has been running for at least three days (this ensures that the tombstones have replicated to other WINS). In this case, the tombstones were timed out but the WINS had not been running for three days. The replica tombstones were deleted. This deletion does not constitute a problem unless there are WINS servers that are primary and backup to clients but not both Push and Pull partners of each other. With the preceding WINS scenario, there is a low probability that this action will result in database inconsistency but if it does, a consistent state can be achieved by initiating consistency checks by using the winscl.exe.</td>
 </tr></tbody></table><p>The following requirements and recommendations apply to a
WINS server that processes a call to <a href="e231089b-eb49-40d2-8b62-2b1437e9f98a" data-linktype="relative-path">R_WinsDoScavenging</a>:</p><ul><li><p><span><span> 
</span></span>Callers to R_WinsDoScavenging SHOULD have control level access.
If an RPC client with a lower access level calls R_WinsDoScavenging, the server
SHOULD return ERROR_ACCESS_DENIED.</p>
</li><li><p><span><span> 
</span></span>The WINS server queues a request on the target WINS server for
the scavenging operation, and the method returns immediately with ERROR_SUCCESS
as the status code.</p>
</li></ul></div>