are you stat[ing] that I am currently getting experience?
That's pretty much it. Just sayin' you've jumped into some relatively deep water and appear to still be breathing. With no programming experience, you're making some pretty good guesses in your coding. They don't work, but they're good guesses.
I guess I should be giving that a try? I will try it.
Definitely. With intellisense and on-board help (click on some word in your code and hit F1) it'll make life a bit easier. And, as suggested, you may want to write a basic DX9 engine and test your routines that way. I'm guessing you have the June 2010 SDK and you could steal a DX9 base engine from one of the examples. If you do that, the debug output goes to the Visual Studio output window automatically when you run your app from VS. With regard to other running apps, I'm afraid I don't know if VS monitors other debug output.
I don't know, but suspect, that debugview or the like will monitor messages to a debug output from a DLL. Also, I've never tried it, but I would think if you launch the main app from a command prompt window that std::cout << "some message\n" or printf("debug message %d", msgNum) could provide you info.
What did you think of my process I outlined? Did it look appropriate?
Without doing a lot of DX9 review and lookups of the docs, I couldn't say. As mentioned, review the docs for functions. A quick look at GetRenderTargetData indicates that what you've got won't work. You don't create the surface before you use it to receive the data. Dx9 (and 10 and 11, for that matter) have requirements for function arguments listed. Don't guess at them, read the docs. Or, as we use to say at work, RTFM!
Just scanning the code without looking anything up, you get the render target data (which, though you call it that, is not the "actual" backbuffer). That's just copied data. You do some manipulations with it, but nothing goes back to the backbuffer.