Hi, Console Application? the old adage is: "When in Doubt, Print more Out". The Macro's __LINE__ and __FILE__ are realy handy there. Write a Dump Function, and do something like: Dump(__FILE__,__LINE__,"Still Alive") That is how you narrow down problems. You know your code, because you wrote it. It is hard to see how an Intellitrace debugger can have a better idea about what you wanted to write in the first place than that you can have. (It could work well in those highly structured Wizzard ridden area's such as Web Matrix. There the Author has no notion of what was written on his behalf, the only thing known to him there is what he wanted to achieve. Commandline Programs? Not very likely Candidates for that technology. When it trashes, you can narrow down where it happens. Also, occasional trashing tends to happen in retail code. Not much code is tested long enough in debug mode to catch an occasional trashing. Even MS Word trashes occasionally, and that is also not always a software issue of your making. Anyway, Debuggers don't work very well with retail code. LogFiles Do! Also, You Don't need to log in Text, You can create your own logging format, plus a (windows) app that can read and display the info. If your code is perfect, but on occasion Windows trashes it anyways, there is little you can do (apart from re-writing Windows) However, What are the Consequences of trashing. Did the User loose their input(inconvenience) or was an entire network or database crashed(Unmitigated Disaster). The former, Let it Go, if it is infrequent. The Latter: write your software mindfull of this, and be aware of the transaction technology you implement or wrote. Hope this is Helpful, :) Bram van Kampen

I think it depends on how often does an ordinary user access registry. When it is used only during the application initialization it is relatively fast.   Of course it has hardware constrains, but again, to the average user (word processing, e-mail etc.) with GB’s of RAM it should make little difference. My “ancient “ PC with circa 380 MB of RAM and 1 GHz processor struggles when I do key searches. I know this is not what you are asking. I guess to get a real answer you need to write a test program to really find out how registry interact with running application. Good luck. Cheers Vaclav

the link answered all my questions thank you :)

thank you David :)

ramana.g wrote: the remote process is crashing How? Where? You must provide details of the crash! We're no psychic! Steve

Hi You must include some MFCXXX.dll beside your executable file in new place. For example MFC42D.dll and ... You can get required files each time you execute your XXX.EXE, because they are requested by the system within a message box! good lock!

The application is a Client, When i perform any operation on Server, the changes should reflect at the Client. I used WinSock 2.2 version for implementation. The server is same, in both the cases. When i run the Server and Client on Machine1 everything is fine. But, when i run the Client Program Macihne2, Client program is crashing. A message is shown saying "The application requested the runtime to terminate".

hmmm should work. The only thing I can think of at this point is that your thread that you pass the socket to needs to have a message loop because the CSocket/CAsyncSocket classes use a window for socket messages. I'm not sure if this is related to the exception you are getting though :confused: When you stepped into the Attach function, how far did it get? Specifically, how far into the CAsyncSocket::AttachHandle() did it go? Did the CreateEx() for the window succeed? We'll figure this out :)