If you run DevHealth on your devices you probably saw dup(d) on the page summary for a process or a dll. It looks something like this:
=== lap_pw.dll page summary: code=0[rom(C):0 ram(c):0] data r/o(R)=0 r/w=0[ro(r)=0 rw(W)=0 exe(E)=0 dll(D)=0 heap(H)=0] page(p)=0 stack(S)=0 dup(d)=0 unknown(?)=0 obj(O)=0 reserved(-)=23
A lot of times it equals 0 but sometimes you see other values. MSDN and Platform Builder documentation has some of the information about DevHealth which you can find here or here on MSDN. Scroll down to "The following table shows the memory information definitions that are included in the page summary" table it has some of the definitions that DevHealth uses in its reports. In the past we received several emails from OEMs concerned that these might be memory leaks because the name kind of suggests it. Please do not be alarmed. It will become clear why in a few moments. First thing that DevHealth does is it checks what’s called a “Secure Section” of the OS. "Secure Section" is a special 32Mb section that lives in Kernel space Slot 93 (c2000000). This section is designed to keep all the DLLs and read/write code that processes load into Slot 0. To put it in other words, if a DLL ever shows up in Slot 0 then it will show up in Secure Section. This is a housekeeping mechanism which allows the loader to only load a particular DLL once greatly increasing the loading speed. When the next process asks for the same DLL, since the OS has it loaded in Secure Slot, it just references that DLL and increments the ref count. In the end Secure Slot is an ORed (logical OR) version of all the DLLs that ever show up in Slot 0. Let's look at an example which will hopefully clarify some things. If we have two Processes. Process 1 which has loaded DLL A and DLL C and Process 2 that has loaded DLL B and DLL C.
<a href= http://humkan.com >american 20arbitration 20association</a>