xcb_get_property_reply returning trash

 Having a problem using xcb_get_property_reply(). I was trying to put 
the finishing touches on my implementation of XDND. I've read and 
reread the specs and tried a couple of ways to get the XdndAware atom 
to work 100% but on 2 different systems of WManagers the reply comes 
back with no error and garbage for the version. The implementation 
handles the trash, but I would rather get it right then apply 
workarounds.
 To explain I'll start with the source window. Getting a window from 
under the pointer, I enter the WM part of my window. My window can be 
defined by 2 windows in the tree, the non-opaque WM part with the user 
window. The non-opaque part breaks into 13 subwindows, one for each WM 
button, the 8 gravity areas, and the content. So leaving the window 
with a drag I enter one of the gravity areas. Once leaving a gravity 
area I enter into a gdk/gtk text window.
 The provided target window found from query routine works 100% as 
expected on gdk text windows. The gravity areas using the target, or an 
attempt at supplying a parent window other than root to check, will 95% 
of the time provide unusable garbage, but looks like dynamic binary 
data of maybe the tree, with 5% of the time proving a number between 
0-5, depending on its mood. Parent trails provides trash on both 
gravity and gdk entries. I've looked at possibility of using the 
tree->parent on the found, but that's the same window for any window I 
enter. If I remember correctly, only a bad window supplied will cause 
an error for reply(). I'm implying that technically all windows are 
XdndAware since they reply and all values are in the range of version 0 
to 0xFF.
 Information on getting pointer: from mouse motion event use the root 
coordinates with the root window to start tree, recursively walk 
visible children to get last top window under pointer. The recursive 
search always starts at highest count of child list to 0, being 
stacking goes bottom to top. Visibility checked by attributes mode.
 Data in hopes to clarify, a few good mixed in:
 From Ubuntu
send XDND_ENTER, target 4194588
received XDND_SELECTION                                   <= Please 
note < 5
send XDND_POSITION, target 4194588
received XDND_STATUS
send XDND_LEAVE, target 4194588
send XDND_ENTER, target 37748744
received XDND_SELECTION
send XDND_POSITION, target 37748744
received XDND_STATUS
send XDND_LEAVE, target 37748744
version > 5 (6746) abort on xdndVersion. target 4194588    <= Please 
note > 5
version > 5 (99) abort on xdndVersion. target 4194588
send XDND_ENTER, target 31457287
received XDND_SELECTION
send XDND_POSITION, target 31457287
received XDND_STATUS
send XDND_LEAVE, target 31457287
send XDND_ENTER, target 37748744
received XDND_SELECTION
send XDND_POSITION, target 37748744
received XDND_STATUS
send XDND_LEAVE, target 37748744
version > 5 (31457288) abort on xdndVersion. target 4194588

 From PDE
version > 5 (10056) abort on xdndVersion. target 48236436
send XDND_ENTER, target 69206039
send XDND_POSITION, target 69206039
received XDND_STATUS
send XDND_LEAVE, target 69206039
version > 5 (69206040) abort on xdndVersion. target 48236436
version > 5 (58545) abort on xdndVersion. target 48236436
send XDND_ENTER, target 69206039
send XDND_POSITION, target 69206039
received XDND_STATUS
send XDND_LEAVE, target 69206039
version > 5 (69206040) abort on xdndVersion. target 48236436
version > 5 (80246) abort on xdndVersion. target 48236436

 Notes on data: I emphasized the Identical targets showing that when it
sent a value under 5 it worked, but sent garbage on a different entry.
I also did not look into why Ubuntu sent XDND_SELECTION, where PDE 
waits til drop.
Assume it's WM doing its thing. That's a entry on the honeydo list.

 Insight into correctly handling xcb_get_property_reply() or XDND 
surely needed!
I only provided what I thought were the basics with enough info. 
Anything else I
would be happy to supply, code, results, etc. But I can't even think of 
additional approaches to get a XdndAware value. And I assume stating 
that cursor drop locations and content work well is enough to state 
pointer transform to window works. Its WM gravity areas that are funky.
Steve