CreateRemoteThread()'s ThreadProc fails, while using try/catch int

[Pravin S. Waghurde]

Hello everbody!!!
I am using CreateRemoteThread() function for injecting the ThreadProc into
one of the windodws service.

Then performing some task and and getting return. This works fine on most
of the system but few of systems get hang once we call CreateRemoteThread().

After i track for the issue i found that when i use try/catch in ThreadProc
the hang issue is occuring and once i remove the try/catch the ThreadProc
complets correctly.

Can any body tell me whats going wrong here. Whether using the try/catch in
CreateRemoteThread()'s ThreadProc is not safe specially when the target
process is windows service.

Thanks for the help in advance.

[Leo Davidson]

On Sep 3, 5:08 pm, Pravin S. Waghurde

 Can any body tell me whats going wrong here. Whether using the try/catch in
CreateRemoteThread()'s ThreadProc is not safe specially when the target
process is windows service.

I'd say that using CreateRemoteThread isn't safe in the first place if
you don't control the code of the target process.

What are you actually trying to do? Maybe there's a better way.

[Chris Becke]

Post by Pravin S. Waghurde
Hello everbody!!!
I am using CreateRemoteThread() function for injecting the ThreadProc into
one of the windodws service.
Then performing some task and and getting return. This works fine on most
of the system but few of systems get hang once we call CreateRemoteThread().
After i track for the issue i found that when i use try/catch in ThreadProc
the hang issue is occuring and once i remove the try/catch the ThreadProc
complets correctly.
Can any body tell me whats going wrong here. Whether using the try/catch in
CreateRemoteThread()'s ThreadProc is not safe specially when the target
process is windows service.
Thanks for the help in advance.

_try & _catch depend on c-runtime support routines. As a different
version of the c-runtime might be embedded in the target process this
could cause problems.

If you arn't already, building with /MT might serve to solve the problem
by isolating the support routines to your own dll.