I recently started using WinXP when I updated my computer. The OS was pre-installed in the new box. Consequently I moved all my toys and tools to the new invironment, including an update to Dstdio 2.6.

Now the problem: There was a piece of software I had previously worked on on my old Win98 box. I had used the nag screen " No can do unless you have the dongle" to break near the protection with the old trick of using HWND command to find out the handle of the nag screen and then BMSG .......wm_destroy.

When I tried the same trick on the XP machine, the behavoir was quite different:

1. The handle of the "OK" button does not belong to the app module, but to one of the kernel dlls, USER32.dll which used to be the case with win98.

2. When I Bmsg to the handle of the dlg window, sice breaks on the application module code instead of the user32.dll as it was typical on W98. Needless to say, the code is not even near the place the nag was generated, (which I know from the Win98 debuging sesion) and is not useful, as it is, to isolate the protection checks.

I realize that the new OS has a different scheme to handle the flow of msgs. However, it seems to spoil and very useful RCE attack point.

Questions: Has anybody observed this behavoir and found a way to work around it So one may still take advantage of message-driven breakpoints??

Thanks in advance

Sorry guys, but I am still stock in the same place.
Perhaps the way I formulated my question is confusing, or its content is so elemental that I don't even deserve a scolding by more experienced members?

This is what I have found so far:

When I break in to a message in WIN98, an address of my application is present in the call STACK, so by patiently tracing back from deep into the USER, USER32 and KERNEL dll, I will eventually return to my app code, within the same call that generated the nag screen.

In WinXP, the USER32.dll has its own call STACK. I have no simple way to determine where, within my code, was the nag screen call generated.
I do not understand how the flow of the program returns to the application once the nag screen is destroyed: If I keep tracing, softIce just disapears, and the program continues its excecution. Is there a way to examine the STACK of the STACKS?