September 27, 2005 at 1:38 pm
I started a debugging session on my client and ran the following (XP firewall disabled):
netstat -an > netstat.txt
from the command line.
The only reference to port 135 was:
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
Is this correct? Is the same port supposed to be open on the server as well?
Thanks for the articles! Yes, the company only gave me one server to work with so I can only debug on that machine. I am trying to get them to purchase another that I could use for staging and/or development.
September 27, 2005 at 1:46 pm
You have to "... see which ports are open between the Client machine and the Remote Server machine". Ping Client and Remote machine. See which ports are open between them
September 27, 2005 at 8:37 pm
Any results? Run Debugging while Firewall is off... and netstat -an > netstat.txt
September 28, 2005 at 5:49 am
No favourable results. As per above, I did open a debug session between server and client and still could not debug....at least to be able to step through the stored procedure. I can open the debug session but it runs to completion and does not allow me to step into/through the code. I turned off the firewall and got the following returned after running netstat -an > netstat.txt:
Active Connections
Proto Local Address Foreign Address State
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 10.0.0.195:139 0.0.0.0:0 LISTENING
TCP 10.0.0.195:1476 10.0.0.200:1433 ESTABLISHED
TCP 10.0.0.195:1477 10.0.0.200:1433 ESTABLISHED
TCP 10.0.0.195:1974 207.46.0.48:1863 ESTABLISHED
TCP 10.0.0.195:1991 10.0.0.6:1052 ESTABLISHED
TCP 10.0.0.195:1994 10.0.0.6:1068 ESTABLISHED
TCP 10.0.0.195:2013 10.0.0.1:139 ESTABLISHED
TCP 10.0.0.195:2053 10.0.0.200:1433 ESTABLISHED
TCP 10.0.0.195:3054 10.0.0.200:445 TIME_WAIT
TCP 10.0.0.195:3056 10.0.0.16:445 TIME_WAIT
TCP 10.0.0.195:3061 10.0.0.200:445 TIME_WAIT
TCP 10.0.0.195:3062 10.0.0.200:139 TIME_WAIT
TCP 10.0.0.195:3063 10.0.0.16:445 TIME_WAIT
TCP 10.0.0.195:3068 10.0.0.200:445 TIME_WAIT
TCP 10.0.0.195:3069 10.0.0.200:139 TIME_WAIT
TCP 10.0.0.195:3070 10.0.0.16:445 TIME_WAIT
TCP 10.0.0.195:3075 10.0.0.200:445 TIME_WAIT
TCP 10.0.0.195:3076 10.0.0.200:139 TIME_WAIT
TCP 10.0.0.195:3077 10.0.0.16:445 TIME_WAIT
TCP 10.0.0.195:3082 10.0.0.200:445 TIME_WAIT
TCP 10.0.0.195:3083 10.0.0.200:139 TIME_WAIT
TCP 10.0.0.195:3084 10.0.0.16:445 TIME_WAIT
TCP 10.0.0.195:3089 10.0.0.200:445 TIME_WAIT
TCP 10.0.0.195:3090 10.0.0.16:445 TIME_WAIT
TCP 10.0.0.195:3095 10.0.0.200:445 TIME_WAIT
TCP 10.0.0.195:3096 10.0.0.200:139 TIME_WAIT
TCP 10.0.0.195:3097 10.0.0.16:445 TIME_WAIT
TCP 10.0.0.195:3102 10.0.0.200:445 TIME_WAIT
TCP 10.0.0.195:3103 10.0.0.16:445 TIME_WAIT
TCP 10.0.0.195:3108 10.0.0.200:445 TIME_WAIT
TCP 10.0.0.195:3109 10.0.0.200:139 TIME_WAIT
TCP 10.0.0.195:3110 10.0.0.16:445 TIME_WAIT
TCP 10.0.0.195:3119 10.0.0.200:445 TIME_WAIT
TCP 10.0.0.195:3120 10.0.0.16:445 TIME_WAIT
TCP 10.0.0.195:3125 10.0.0.200:445 TIME_WAIT
TCP 10.0.0.195:3126 10.0.0.200:139 TIME_WAIT
TCP 10.0.0.195:3127 10.0.0.16:445 TIME_WAIT
TCP 10.0.0.195:3132 10.0.0.200:445 ESTABLISHED
TCP 10.0.0.195:3133 10.0.0.200:139 TIME_WAIT
TCP 10.0.0.195:3134 10.0.0.16:445 ESTABLISHED
TCP 10.0.0.195:3138 10.0.0.1:9127 SYN_SENT
TCP 10.0.0.195:3347 10.0.0.1:1433 ESTABLISHED
TCP 10.0.0.195:3735 10.0.0.16:1433 ESTABLISHED
TCP 10.0.0.195:3751 10.0.0.200:1433 ESTABLISHED
TCP 127.0.0.1:1028 0.0.0.0:0 LISTENING
TCP 127.0.0.1:1970 0.0.0.0:0 LISTENING
UDP 0.0.0.0:445 *:*
UDP 0.0.0.0:500 *:*
UDP 0.0.0.0:1027 *:*
UDP 0.0.0.0:1038 *:*
UDP 0.0.0.0:1039 *:*
UDP 0.0.0.0:1049 *:*
UDP 0.0.0.0:1873 *:*
UDP 0.0.0.0:1980 *:*
UDP 0.0.0.0:1992 *:*
UDP 0.0.0.0:2967 *:*
UDP 0.0.0.0:4500 *:*
UDP 10.0.0.195:9 *:*
UDP 10.0.0.195:123 *:*
UDP 10.0.0.195:137 *:*
UDP 10.0.0.195:138 *:*
UDP 10.0.0.195:1900 *:*
UDP 10.0.0.195:12908 *:*
UDP 127.0.0.1:123 *:*
UDP 127.0.0.1:1900 *:*
UDP 127.0.0.1:1971 *:*
UDP 127.0.0.1:2930 *:*
Does the top entry indicate that port 135 is open? Is that the port that the debugger uses? Should I do the same on the server?
September 28, 2005 at 7:48 am
Found this in the server application log:
Event Type: Error
Event Source: SQLDebugging98
Event Category: None
Event ID: 1
Date: 9/26/2005
Time: 4:33:19 PM
User: N/A
Computer: SED-SERVER
Description:
SQL Server is running as 'SED-SERVER\Administrator' and cannot connect to the debugger on machine 'SIS2XPTEST' (error = 0x80070005 Access is denied. ). Use one of the following options to fix this error. 1) Run SQL Server as "Local System", as a domain account, or as a local account with identical usernames and passwords on both machine 'SED-SERVER' and 'SIS2XPTEST'. 2) Verify that machine 'SED-SERVER' can open files on machine 'SIS2XPTEST'. Debugging disabled for connection 52.
How would I go about verifying 2?
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
September 28, 2005 at 10:44 am
I assume you have enough permissions on both machines. Try adding ports 445 and 139. Also please add Query analyzer to the exception list.
September 28, 2005 at 10:55 am
I have administrative access on both machines. Added TCP ports 445 and 135. Added Query Analyzer to the Exceptions list. Shouldn't matter anyway cause I have the firewall turned off. Any other suggestions?
September 28, 2005 at 11:12 am
Ensure on Both machines: Administrative Tools -> Services.
"Remote Procedure Call" should be started.
SQLDebugger Account on the Server should not be Disabled.
Ensure SQLDebugger has "Log on as a batch job" and "Deny logon locally" user rights.
Ensure that under COM Security-> Access Permissions ( and also under Launch and Activation Permissions)->Edit Defaults you allow Local and Remote Access.
September 29, 2005 at 10:31 am
Did it help?
September 30, 2005 at 9:51 am
I apologize for the delayed reply Barsuk. I did get it to work but only after doing the following:
1. Applying SQL Server 2000 Service Pack 4 to both client and server.
2. Creating an account on both client and server with administrative priveleges.
I didn't want to leave anyone hanging with regards to this post. There appear to be others with the same/similar problems. I have seen this in the past and nobody benefits. It seems as though some people either quit responding to posts or, if they do find the solution to the problem themselves, either don't post the solution or forget to do so. I am grateful for your persistence since it eventually got me thinking and led to the eventual solution. Thanks so very much for your time and efforts and I only hope that I can return the favour to someone else.
Just one quick question, I have the SQL Server 2005 Standard Edition CTP for September (just the client tools) on my local machine, and I was wondering if you knew how to debug in 2005 against a 2000 database. There is no long Query Analyzer, but rather the "Management Studio" environment. Or an article discussing this topic would be great as well.
Thanks
Cory
September 30, 2005 at 10:20 am
Thanks for posting Cory. I have been following your posts because I am in the same situation, except that for the moment I can pop over to my other machine to debug. When I get a moment, I plan on following your steps!
Linda
September 30, 2005 at 11:23 am
Quick note, Cory: I thought you already have SP4 installed, since I recommended installing hotfix 944 otherwise earlier.
September 30, 2005 at 1:27 pm
I did on both client and server but it was the permissions issue that was preventing me from using the debugger properly.
December 14, 2005 at 10:50 am
Cory,
This has been a very interesting and helpful thread. Can you please confirm that in the end, steps 1 and 2 were all you needed to do to solve the issue?
Also, can you explain step 2 in more detail. I'm not quite sure what the account you mention is to be used for.
Many thanks.
- Mike
Viewing 14 posts - 16 through 28 (of 28 total)
You must be logged in to reply to this topic. Login to reply