_asm { int 3 } doesnt work with VS2005 and VS6 on same machine

[Dave]

I have a TSP (Telephony Service Provider) that I've developed with VS6.
It's a C/C++ DLL that gets loaded by a svchost and accessed by TAPI based
applications. My problem is that on the Windows XP machine that I have the
application on I can no longer break into the debugger using an "_asm { int
3 }". This code worked until I installed Visual Studio .Net. The system
I'm running this on has both Visual Studio 6 and VS 2005 running on it. I
have some registry scripts that I use to switch my default debugger between
the 2 when necessary. I have other machines with just VS 6 on them that
this technique works fine on, but a problem I'm trying to debug is on this
dual environment machine.

Anyone have any suggestions ?

Dave

[Gary Chang[MSFT]]

Hi Dave,

>My problem is that on the Windows XP machine that I have
the application on I can no longer break into the debugger
using an "_asm { int 3 }". This code worked until I installed
Visual Studio .Net. The system I'm running this on has both
Visual Studio 6 and VS 2005 running on it.

_asm { int 3 } should works well with VS2005 on a XP machine. I have
performed some tests on this issue, my test machine also installed the VC6
and VS2003, there is no problem on my side.

In order to dig into this problem, would you please provide more
information on this issue?

Generally, the _asm { int 3 } will cause an unhandled Win32 exception, does
that exception occur while you test the program? If the exception occurred,
the system will prompt a dialog window for you to choose the debugger to
debug the program? Do these behaviors happen in your machine? If you not,
what happens on your side?

Thanks!

Best regards,

Gary Chang
Microsoft Online Community Support
=============== =============== =============== =====
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no rights.

[Dave]

Gary Chang,

Let me give you a few more details. The software I'm debugging is a TSP
(Telephony Service Provider). A TSP is a DLL that resides within the
context of a svchost. The particular svchost that my DLL resides in, is in
the SYSTEM user context. This mean's I will either need to reconfigure my
XP to run the telephony services within the logged in user context or not
use the asm int 3 technique at all anymore and just attach the debugger to
the svchost that the telephony services are running under. My guess is that
the asm int 3 is popping up the debugger exception to the system user
login. Is this correct ?

Thanks
Dave

""Gary Chang[MSFT]"" <v-******@online.m icrosoft.comwro te in message
news:up******** ******@TK2MSFTN GXA01.phx.gbl.. .

Hi Dave,

My problem is that on the Windows XP machine that I have
the application on I can no longer break into the debugger
using an "_asm { int 3 }". This code worked until I installed
Visual Studio .Net. The system I'm running this on has both
Visual Studio 6 and VS 2005 running on it.

_asm { int 3 } should works well with VS2005 on a XP machine. I have
performed some tests on this issue, my test machine also installed the VC6
and VS2003, there is no problem on my side.

In order to dig into this problem, would you please provide more
information on this issue?

Generally, the _asm { int 3 } will cause an unhandled Win32 exception,

does

that exception occur while you test the program? If the exception

occurred,

the system will prompt a dialog window for you to choose the debugger to
debug the program? Do these behaviors happen in your machine? If you not,
what happens on your side?

Thanks!

Best regards,

Gary Chang
Microsoft Online Community Support
=============== =============== =============== =====
Get notification to my posts through email? Please refer to

http://msdn.microsoft.com/subscripti...ult.aspx#notif

ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no

rights.

>

[Gary Chang[MSFT]]

Hi Dave,

>My guess is that the asm int 3 is popping up the debugger
exception to the system user login. Is this correct ?

yes, you are right. I am afraid I missed the point that your DLL is loaded
by a service process. In this scenario, if no debugger has already been
attached to that process, the INT 3 will throw an unhandled Win32 exception
and invode the debugger of the system logon session, which is invisible to
the current user.

I suggest you can attach your VC6 or VS2003 debugger to that service
process before the INT 3 occurs, it should work.

Thanks!

Best regards,

Gary Chang
Microsoft Online Community Support
=============== =============== =============== =====
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.
=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no rights.

[Dave]

Gary,

Already figured that out, but thanks for your response.

Dave

""Gary Chang[MSFT]"" <v-******@online.m icrosoft.comwro te in message
news:CA******** ******@TK2MSFTN GXA01.phx.gbl.. .

Hi Dave,

My guess is that the asm int 3 is popping up the debugger
exception to the system user login. Is this correct ?

yes, you are right. I am afraid I missed the point that your DLL is loaded
by a service process. In this scenario, if no debugger has already been
attached to that process, the INT 3 will throw an unhandled Win32

exception

and invode the debugger of the system logon session, which is invisible to
the current user.

I suggest you can attach your VC6 or VS2003 debugger to that service
process before the INT 3 occurs, it should work.

Thanks!

Best regards,

Gary Chang
Microsoft Online Community Support
=============== =============== =============== =====
Get notification to my posts through email? Please refer to

http://msdn.microsoft.com/subscripti...ult.aspx#notif

ications.
=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no

rights.

>

[Gary Chang[MSFT]]

You are very welcome, Dave. :)

Good Luck

Best regards,

Gary Chang
Microsoft Online Community Support
=============== =============== =============== =====
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.
=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no rights.