I am trying to attach to w3wp.exe to debug classic asp.
i am attaching to type "Script", but get the following error:
Failed to attach to these type(s) of code: Script: A debugger is already attached.
i saw online that maybe another program is running on the background and is using "Script".
how can i find out what program uses it? and possibly kill it? or is there another way to go around it.
maybe i can debug classic asp without attaching to Script? this is the only way i've been able to do it in the past.
Thanks!
you have to configure asp in your iis and set server-side debugging to true.
then you can use the "stop" keyword in your asp script in the line you want to set a "break Point". when the line is executed a window will popup and you can start visual Studio to debug your asp script.
Related
I have to debug a classic asp site being served by IIS 7 (windows 2008).
How can I do this? I have only worked with ASP.NET.
From an MSDN blog post: http://blogs.msdn.com/mikhailarkhipov/archive/2005/06/24/432308.aspx
Here is how to make ASP debugging work:
Enable ASP debugging on the server. (I also added DEBUG verb to the asp extension, but I am not sure if it is required).
Open classic ASP in VS 2005.
Set breakpoint.
View page in browser or run without debugging.
Debug | Attach to Process
Locate IIS ASP worker process (w3wp.exe on IIS6) which exposes x86 and Script and attach as Script.
From eddiegroves comment below:
Regarding Step #1 in IIS7 - IIS > ASP > Compilation > Debugging Properties > Enable Server-side Debugging
I realize this is old, but thought I'd reply to help others since I was looking something else up.
You can use Visual Studio to debug Classic ASP.
If you're running a local copy of IIS, just attach the debugger to the w3wp.exe process and you can set breakpoints, add variables to watch windows, etc.
If you have more than 1 website, it's helpful to run each in a separate application pool, and you'll be able to identify different w3wp.exe process in the Attach Process window.
Just choose "script" as the debugger type. If you're running IISExpress, then the iisexpress.exe process is the correct one to attach to.
I've found that a useful setting to enable is found at the server level under ASP > Compilation > Debugging Properties > Send Errors To Browser. Set that to "True".
This may not be appropriate under all circumstances (e.g. for an internet-accessible site).
Built in classic ASP debugging is pretty poor. I put together this ASP include class which works with Firebug+FirePHP. It allows you to log values (including strings, multi-dimensional arrays and even objects created with json.asp) to the firebug console and view ASP's built in collection objects which can help (particularly with Ajax where you can't output debug data without breaking the json response.) Ajax script load times and errors are automatically logged for quick viewing.
https://github.com/dmeagor/ClassicASP-FirePHP
Released under MIT open source license
This is the way I figured it out:
Put a stop (write stop) on the place where you want to hit the debug point. Then run the application on browser. When the execution comes to stop it will open up debug popup asking do debug with Visual studio (a VS version must be installed). Then it will ask to attach the process and you can use f10, f11 to go step over and in. You can see the data using add watch.
I use the following (which I got from somewhere online) to write to a log file. I would prefer a method for writing directly to Console in Firefox or Chrome, but this works pretty well for me.
NOTE: "timestamp" is a custom function of mine. You can probably guess what it does, and probably roll your own. ;-)
function error_log( message )
dim objFSO, objLog
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objLog = objFSO.OpenTextFile( "ASP_errors.log", 8, true)
objLog.WriteLine "[" & timestamp & "] VBS Message: " & message
objLog.close
set objLog = nothing
set objFSO = nothing
end function
host your site on IIS server.
enable remote debugger on IIS server.(follow this tutorial)
import the source code into visual studio.
install remote debugging tool from here
In the remote debugging tool select tools-> options -> no authentication for all users.
Go to visual studio and attach to process w3wp.exe.
if cant see the process (w3wp.exe). Open the website link in browser and select show for all users
now u will be able to see the process and attach.
Dont forget to put a debugger in the application :-)
I have an Excel-DNA project in C# using .NET 4.0 using Visual Studio 2010/2015.
If I start Debug and use the "Start external program" feature to launch EXCEL.exe I am able to pause the debugger and Edit & Continue works perfectly fine.
However, if I try to attach to a running EXCEL.exe process I get an error message saying Edit & Continue is not supported for one of various reasons. When selecting to attach to a process I only have "Managed (v4.6, v4.5, v4.0)" selected.
The error message states:
Changes are not allowed in the following cases:
- Attached to a process that does not support Edit and Continue on attach.
- The code being debugged was optimized.
- The assembly being debugged is loaded as domain-neutral.
- The assembly being debugged was loaded through reflection.
- Intellitrace events and call information is enabled.
- The .NET Runtime this program is running does not support edit and continue.
What is the difference between these two scenarios? What does "Start external program" do differently than manually attaching?
This is well documented:
Edit and Continue is not available in the following debugging scenarios:
Debugging an application with Attach to rather than running the application with Start from the Debug menu.
The workaround you found by using the "Start external program" option is the correct approach.
I've been following this guide to debug a Windows Service application.
Basically, I need to attach the Visual Studio debugger to the process started after installing the Windows Service that has been developed. However, VS doesn't allow me attach the debugger to this process as shown in the following picture:
How can I attach the debugger to this process? If I clicked on any of the other processes the Attach button becomes enabled.
Any help would be greatly appreciated
check the checkbox Show processes from all users, then you will see AutomatedReports.exe. Attach that (not AutomatedReports.vshost.exe)
vshost is a host process to help with the debugging. More info on this MSDN Link
Also you need to place the following line in your service code where you want to hit the break point.
System.Diagnostics.Debugger.Break();
The service is probably running on a separate user account. Check the "Show processes from all users" checkbox and attach the debugger to AutomatedReports.exe process.
Also make sure that you are running a Debug build of the service, otherwise, you won't be able to debug a lot.
Have you tried to change the type of the code you are debugging?
Click on "Select ..."
Select "Debug these code types"
You can then select Types like: “Managed (v4.0…)"
Is there any way to use the "Run As" option in Windows XP in conjunction with Visual Studio's debugger, to debug an issue that occurs in my application only when certain users are logged in?
I have ran the application from my machine using "run as" to pretend to be the user in question, and I got the same error as they did. I would like to debug this error and see where and what exactly is causing it. The error occurs specifically when a certain domain user is logged in, and never otherwise.
Is there any script or approach I can take to debug this error; that is too launch the application, as the problem user, and then use the debugger?
Trying to attach to the process didn't work since it was a C# managed process and VS didn't let me attach.
The first two options that come to mind are...
Log onto the machine as the user (simplest approach)
Right-click on the Visual Studio executable and run as that user.
I think that you could edit the .config file to use impoersonation, but I'm not sure if that will result in the app running truly the way it would for the user.
Although with good error handling, the error message itself should be enough to tell you where in the code the problem is... At the very worst, you could compile it in debug mode (so you have all the symbols) and add some global error hanlding and get the exact stack trace...
I use David Strattons second solution (run as Administrator) because my application requires administrator privileges (-> elevated).
Another solution could be to start the application as the user and use "Debug | Attach to process..."
Recently I tried to install a webpart through wspbuilder utility to the Sharepoint Site. I have created, built and deployed a project to the 12 hive. After that installed the solution through Cental Administration Site and activated in the site collection.
I just wonder how can I debug the complex feature/solution ? Because both processes (build-deploy and activate) totally independent, how can I attach a process with the worker process ?
In the WSPBuilder context menu there is an option "Attach to IIS worker process". As long as the app is loaded (generally means that you have accessed a page in the SharePoint site before trying to attach) and the code deployed in SharePoint is the same as the code you have in Visual Studio, you should be able to set breakpoints and step through the code.
First, you need to open up your browser and navigate to the SharePoint website in question. Then, In Visual Studio, go to Debug --> Attach to Process, and find the w3wp.exe process associated with the Sharepoint website that you want to debug. Click it (the process) and then click the Attach button. You should now be able to debug any activities associated with your SharePoint feature.
Sometimes it is a bit of a pain to figure out which w3wp process to attach to. Try adding the following to your code to break into the debugger:
System.Diagnostics.Debugger.Break();
System.Diagnostics.Debugger.Break()
Like Muhimbi suggested, this is actually very useful in certain cases. Say you want to debug custom code (e.g. feature_deactivating event) when it might be invoked with stsadm and not the browser. (for e.g. you will have to use stsadm for feature deactivation when feature is hidden in UI).When using stsadm you cannot attach to cmd.exe because that's a separate process. If you type the command and hit enter and then find its id of stsadm.exe process to attach to, its too late. In situations like these, the command above is the easist and best solution
I tried the steps as mentioned here
go to Debug --> Attach to Process, and find the w3wp.exe process associated with the Sharepoint website that you want to debug
But I get "Breakpoints will not be hit, no symbols have currently been loaded for this document". Should I have to register the custom deployed solution dll using GACUTIL ? Should I have to copy the PDB files at any particular location ?
What am I missing here ?