Debugging in SSMS exits without stepping in to code

I've recently put Windows 7 on my development PC, and I have Visual Studio 2008 Team System Development Edition, and SQL Server Management Studio 2008, and for some reason I can't seem to step in to any SQL code for debugging in SSMS.

Before I formatted in favour of Windows 7, I was able to debug on the same two SQL servers I'm trying now with the same software, so I'm guessing it's something to do with client configurations. Regardless, I tried all the steps I could find to enable SQL remote debugging but nothing has worked.

When I attempt to debug or step into the active query window, the debugger simply runs the code without stopping at the start or any breakpoints.

If I try use Visual Studio (running as Administrator) I get the following error:

T-SQL execution ended without debugging. You may not have sufficient permissions to debug.

Anyone got a clue what to do here?

EDIT

I'm still having this problem. I re-installed the latest SQL Server Management Studio from MSDN's latest SQL Server 2008 download available, and patched it with SP1, but this same problem still happens. Other people in my office are able to debug code with the same version client, and same permissions (set using gr开发者_如何学Coup permissions) so I'm at a loss as to what is causing this.

FINAL EDIT

Solved! The issue was simply a domain authentication issue. See my answer for a larger explanation.

Have you made sure that in Server Explorer (In Visual Studio), if you right click on your connection that you have "Allow SQL/CLR Debugging" and "Application Debugging" checked?

Today, I finally solved this.

I was writing an ASP.NET application that included the line:

User.IsInRole("DOMAIN\\Administrators");

And this was throwing the following exception:

The trust relationship between this workstation and the primary domain failed

I wasted a little time applying the KB976494 hotfix, which I soon discovered didn't work. During my developer rage I looked in my local "Administrators" account and noticed it listed almost all members by their S-ID, so figured there may have been a domain problem.

Then it came to me... I remembered I joined the domain with my personal (non-administrator) account, instead of using the domain administrator account.

These were the ultimate steps to fix this issue:

1. Leave your domain (and join an arbitrary workgroup, such as "WORK")
2. Reboot.
3. Join your domain with your "DOMAIN\Administrator" account

User.IsInRole() now worked, so out of curiosity I checked this problem, and it was also fixed.

This is a great Friday so far!