Share via

How to resolve "Cannot debug pid , NTSTATUS 0xC0000048" - "An attempt to set a process's DebugPort or ExceptionPort was made ..."

  • Article

 

 

Once I found out what was causing this error message it was pretty obvious what was going on.

But when investigating there was not much information to be found so I thought I’d share this with you.

The ones who are more seasoned debuggers may think that this is stating the obvious but we who are not there yet may be helped by this J

Basically I wanted to debug a running w3wp.exe process.

So I fired up WinDbg, hit F6 for attaching to a process and selected the w3wp.exe process and was presented with this:

Cannot debug pid <pid>, NTSTATUS 0xC0000048

 

"An attempt to set a process's DebugPort or ExceptionPort was made, but a port already exists in the process or an attempt to set a file's CompletionPort made,

but a port was already set in the file or an attempt to set an ALPC port's associated completion port was made, but it is already set.

So I went about to do some research but couldn’t find any clear cut cause for this.

I tried to run the debugger as administrator. I closed all my programs and then I rebooted my machine but nothing helped.

In the end I learned something new.

That was that even if you restart the machine when you have an active rule running in Debug Diag this rule will auto activate after the reboot even if you have not restarted the Debug Diag tool.

 

So once I found this and stopped the rule in Debug Diag I could successfully attach to my process.

Comments

  • Anonymous
    February 29, 2012
    The comment has been removed

  • Anonymous
    March 08, 2012
    Thank you for your sharing. Helped me directly.

  • Anonymous
    June 26, 2012
    Great post! Solved my problem instantly.

  • Anonymous
    July 01, 2012
    Wow you solved one of my big troubles. Thank you so much!

  • Anonymous
    September 05, 2013
    Another cause for this is trying to attach the 32-bit version of WinDbg to a 64-bit process. In that case, the solution is simple: use the 64-bit version of WinDbg. Check the bitness for the process in Task Manager if unsure. Perhaps this is what umesh was experiencing.