There are several issues to consider here:
1) Does the developer have rights to use the debugger? None of the developers in my current environment would have rights to use the debugger.
2) Will the debugger work for this procedure? I have used the debugger and have found that there are some procedures it is unable to work on.
3) As far as I was able to determine the debugger will not let you see the contence of temp tables or for that matter table variables.
4) Does the developer have access to sql profiler? This will at least tell you the path that proc is using.
Depending on the type of issue and how the proc is written:
1) Is it operating on one record at a time?
2) Is it operating on sets?
3) Does it use temp tables or table variables?
The best way to go sometimes is to execute the procedure as inline SQL in Query Analyzer so that you can examine all information at each step of the way. The included debugger will sometimes help to debug issues but it is VERY primitive and limited.
Cast has a SQL debugger that I used several years ago (SQL 6.5). It was solid and helped me debug many complicated procedures and triggers. It had some concurrency issues but was a superb product.