I resisted answering this question at first because I usually find that when I try to help people with cracking I end up being a bit long-winded and never getting a reply, so I don't know whether I've really helped anyone at all. Bear in mind that my answer will be long because of the nature of cracking/reverse engineering, because it is an involved process that I am attempting to describe. with cracking you have to constantly think about how a program works, and it really helps if you're a programmer or have experience cracking, and try different approaches based on that. the moment you reach the ends of your knowledge and creativity is when you stop having ideas for what approaches to take, in which case you need to learn more (by studying the program or programming in general) or think about it more. there is no set procedure, although there are procedures that often yield results. I'll state some of them here, but remember that none or all of these methods may work. to get better at cracking you need to practice, practice, practice (and read programming and cracking tutorials)... and I'm very aware of the catch 22 here, it sucked for me starting out too.
since you have found where the key you inputted is stored in memory (or at least one copy of it), have you tried placing a memory access breakpoint on that memory address? that will tell you when the program loads or compares the memory directly to something else. if you know that you have found the original copy, then tracing the transfer of the key in memory should eventually lead you to the final comparison/check. if it isn't the original copy then you should try to find it... if you're lucky then placing a memory write breakpoint on the address you found might work, but you will probably have to find the API the program uses to read the registration you entered from the text box, and begin tracing execution from there to determine where the comparison happens. I don't remember the APIs off the top of my head, if you're interested I'll hunt my references down for you and post them.
alternatively to all that, you could try the approach that you're using, just extended. you've found where the message box (or whatever the program uses to inform you that your key is horseshit) is called by the program, so *probably* at some earlier branch in its current execution it made the determination, and then set a flag or variable that it's looking at for the false validation message. so you need to trace back through the program to find where the actual comparison is made. you could try a memory write breakpoint on that flag/variable to find where it is written, and try correcting the jump that makes that determination there (or if there's another comparison then just apply the same procedure again).
OR you could try tracing the execution back by either tracing through the call stack or by placing breakpoints at the return(s) of each function and letting the program go until the breakpoint trips, then stepping until you are out of the function. the call stack is usually faster, but you have to know what you're looking at. either way, at each function you find you should look at what's being passed (pushed to the stack) to the function, and what it returns (usually what is in the EAX register after it has executed), and most importantly what is done with the return value immediately after. you can usually judge when the key comparison is done (in what function) by those parameters.
this all assumes that your program isn't hardened against cracking (it probably isn't).
well thank you for help ill keep trying..
this is the most important part
you have to keep trying things, and learning things about the program, until you have it. expect it to take a very long time.