A security package specific error occurred - Remote debugging Windows 2003 code from Windows 7/2008 R2 - by Lord Zoltan

Status : 

  External<br /><br />
		This item may be valid but belongs to an external system out of the direct control of this product team.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 508455 Comments
Status Closed Workarounds
Type Bug Repros 5
Opened 11/5/2009 3:46:19 AM
Access Restriction Public


I have a Windows Service running on a Windows Server 2003 x64 machine.  I have the Remote Debugger Service (from VS 2008 Sp1) running on that machine, with all permissions set to allow the development team to connect and debug.

The remote debugger service runs as a domain account that has administrator privileges.
When running Visual Studio 2008 Sp1 on a Windows Server 2003 development machine, we were able to connect without problems.

Now I am migrating to Windows Server 2008 R2 as my development platform, and I am no longer able to connect to the remote machine with the remote debugger without the use of a workaround involving the creation of local users (see workarounds).

Closer inspection (by switching on Network NTLM Auditing via Local Security Policy, and then examining the Security event log on the developer machine) shows that the process fails at some point after the debuggee machine reverse-authenticates back to the development machine using the credentials under which the debugger service is running.

Although authentication is successful, it appears that the logon sessions are then destroyed immediately afterwards.  Whether this is a symptom, cause, or just a side-effect I cannot be sure.

My thinking is that there is an incompatibility with the network-logon NTLM token that is sent by the 2003 machine to the 2008 R2 when the reverse authentication occurs.
Sign in to post a comment.
Posted by Joshua Beall on 1/19/2011 at 8:29 AM
Additionally, it's worth pointing out that the component that doesn't work, from the user's perspective, is a part of Visual Studio. In other words, a user attempts to use remote debugging inside Visual Studio, and it doesn't work.

It would seem to me that a part of providing a good user experience is making sure that your product works correctly--regardless of what's going on internally that might be the culprit. Right?

And it's not like this doesn't work "sometimes" -- it simply *never* works for users of Windows 7 or Server 2008.
Posted by Joshua Beall on 1/19/2011 at 8:23 AM
The workaround posted does not work for me. I created an identical machine user account on both machines, and made it a member of the local administrators group. I then logged in on the workstation (with Visual Studio 2008) and on the server (running MSVSMON) and attempted to attach. I got an error saying both VS and MSVSMON have to be running as administrators.

Ok, no problem--restart the both apps as administrators. I did so, and then attempted to attach again. This time, MSVSMON crashed. It continued to do this every time I tried, except once--when it allowed me to attach the VS debugger, and then crashed about 30 seconds later, after stepping through about 10 lines of code.

Here's the crash info:


Log Name:     Application
Source:        Windows Error Reporting
Date:         1/19/2011 11:06:23 AM
Event ID:     1001
Task Category: None
Level:         Information
Keywords:     Classic
User:         N/A
Computer:     DEV-WEB-2008
Fault bucket 18300881, type 4
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: msvsmon.exe
P2: 9.0.30729.1
P3: 488f0767
P4: ntdll.dll
P5: 6.1.7600.16559
P6: 4ba9b802
P7: c0000005
P8: 0000000000051c30

Attached files:

These files may be available here:

Analysis symbol:
Rechecking for solution: 0
Report Id: 00c4b658-23e6-11e0-9bee-001ec9d3c29a
Report Status: 0
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    <Provider Name="Windows Error Reporting" />
    <EventID Qualifiers="0">1001</EventID>
    <TimeCreated SystemTime="2011-01-19T16:06:23.000000000Z" />
    <Security />
    <Data>Not available</Data>



Log Name:     Application
Source:        .NET Runtime
Date:         1/19/2011 11:06:24 AM
Event ID:     1023
Task Category: None
Level:         Error
Keywords:     Classic
User:         N/A
Computer:     DEV-WEB-2008
.NET Runtime version 2.0.50727.4952 - Fatal Execution Engine Error (000007FEF757B4DF) (0)
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    <Provider Name=".NET Runtime" />
    <EventID Qualifiers="0">1023</EventID>
    <TimeCreated SystemTime="2011-01-19T16:06:24.000000000Z" />
    <Security />
    <Data>.NET Runtime version 2.0.50727.4952 - Fatal Execution Engine Error (000007FEF757B4DF) (0)</Data>
Posted by antid0tcb on 5/8/2010 at 8:07 PM
This isn't closed issue. Don't lie, plz. Kerberos authentification don't work between W2K3Svr & Windows 7
Posted by Lord Zoltan on 12/8/2009 at 4:30 AM
I've posted a 'suggestion' on the Windows 2008 connection: https://connect.microsoft.com/WindowsServerFeedback/feedback/ViewFeedback.aspx?FeedbackID=518848.
Posted by Lord Zoltan on 12/8/2009 at 4:15 AM
Okay, thanks - I fully accept your explanation.

It's a shame, though, that the Windows Server 2008 connection only supports 'suggestions' rather than bugs. So we'll see how far this one goes!
Posted by Microsoft on 12/4/2009 at 11:29 AM

The issue that you are encountering here is a Kerberos authentication issue, which is used by Windows for domain level authentication. This is a component owned by the Windows team, so I am going to resolve this bugs as "external" and I would recommend filing a connect bug with Windows.

Best Regards,
Andrew Hall
Visual Studio Debugger
Posted by Lord Zoltan on 11/11/2009 at 12:37 PM
Many thanks for your attention,

I look forward to receiving future updates,

Posted by Microsoft on 11/11/2009 at 1:00 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you
Posted by Microsoft on 11/9/2009 at 12:47 AM
Thank you for your feedback, We are currently reviewing the issue you have submitted.