A bit of a late answer, but I wanted to correct the answer chosen here. Yes, it's true that the VS provided COM wrapper may use a different UIAutomationClient.dll, and that using native code will be different to managed code while calling UIAutomation methods, but nonetheless the question asked here is a different issue. (By the way, you can use a COM wrapper from managed code to call the correct version of the UIAutomation dll's, which will solve issues like "inspect.exe finds it but my managed code cannot").
I also ran into the problem asked here (mine was: FindAll(TreeScope.Children, TrueCondition) not returning anything although FindFirst() was successfully returning children on the same control).
I tried mike-z's approach using RawViewWalker to find children and it worked fine for this case. I'm writing this separate answer to say that it wasn't Find* methods being the problem, but a difference between FindAll & FindFirst methods that caused August's problem.
Update
Inconsistent behavior seems to be the norm when it comes to MS tools. The reason for this update is, I've bumped into a similar issue with my tlbimp.exe'd RCW for uia using C#, and this time I wrote a direct equivalent C code and to my surprise it was working perfectly while the C# code refused working in any way while trying to find a simple OpenFileDialog's controls, then another control on the main form. The only difference between the two worlds is the mysterious MS RCW magic. I'm not sure if it's the way the marshaling is handled with the automatically created COM wrappers (by tlbimp) or something else. And the [ComConversionLoss] attribute that appears for the created interface doesn't sound right to me. Anyways I'm now considering manually crafting the COM interface or converting my whole project to native environment.