4

Scenario:

  • Delphi ISAPI dll written using Delphi XE, 32 Bit.

    ISAPI dll is running through IIS 7.5 on a Win 7 64 enterprise desktop machine.

    DLL runs fine.

    Debug the ISAPI DLL in the Delphi XE IDE by using Run->Attach to Process:

    Launch the ISAPI DLL and attach to the wpw3.exe *32 process in the debugger - can trace and debug code as it runs in the ISAPI context.

Problem:

  • My hard drive died last week and I got a new Win 7 installation - the standard corporate wide Win 7 64 Enterprise image (not the same as my previous Win 7 64 installation).

    Now, when I go into Run->Attach to Process, I no longer see the wpw3.exe *32 process by name, although it is visible in task manager by name. Invoking the 'show system processes' option on the 'Attach to Process' Dialog box does not help.

    What I DO see now (which I never saw before in my old deployment) is a long list of 'generic' System process with PID's but no descriptions other than 'System'.

    One of these processes is my wpw3.exe *32 process, and I have identified its PID using MS's Process Explorer. But if I try to attach to that process I get an error message - 'Cannot create process - access denied' - so I can't debug. (Same error message 'Error Opening process, Access denied' also shows in Process Explorer for certain properties, although the descriptive name of the process ' wpw3.exe *32' is visible there, associated with the PID.)

    How can I get the Run->Attach to process dialog box to display the proper wpw3.exe *32 process name and attach to it, so I can debug?

    Is this a Delphi problem? An IIS problem? An ISAPI problem? Is this one problem - ie lack of descriptive process name and inability to attach to process are caused by same problem; or is this two problems: one problem being lack of descriptive name, another the inability to attach to the process?

    (Do not want to use - cannot really use - webApp debugger for this - these are ISAPI dll's that are deployed to production exactly as they are written and debugged in IIS - I need to see them running in IIS context.)

  • Been debugging ISAPI dll's for several years this way, with different versions of Delphi and in various OS and server environments without any problems - never encountered this problem before. I am stumped.

Vector
  • 10,879
  • 12
  • 61
  • 101
  • 2
    Since you just got a new OS installation, this sounds like an OS configuration issue. Are you an administrative user? If not, does your user account have the `SE_DEBUG_NAME` privilege (which allows you to debug processes not owned by you, which would include IIS loaded DLLs)? A quick search of MSDN yields [these links](http://social.msdn.microsoft.com/Search/en-US?query=SE_DEBUG&ac=3), which may be of some help. – Ken White Sep 13 '12 at 23:36
  • I am a local admin and the process runs under my identity. But it is spawned by IIS so it's not entirely mine. In task manager it is not visible unless I click 'show processes from all users'. But when task manager does display it, the user name is mine. I assume that's because IIS spawns the process. I will check out the links, etc. Thanks! – Vector Sep 14 '12 at 00:28
  • 1
    Thing is Ken, I've never had to deal with this before - but I have feeling that the corporate Win 7 image has been locked down and messed with in ways that I can't control.... – Vector Sep 14 '12 at 00:53
  • 2
    I sympathize. :-) Corp policies and developers usually don't play well together. You may need to contact the powers that be to get some changes made as a dev., though. I don't think this is really an issue that can be resolved without OS rights changes, and if you can't make those yourself you may not have a choice in the matter. (I could be wrong, though; I'm not up on ISAPI debugging in recent versions of IIS/Windows, so it could be something else; that's why I posted a comment instead of trying to post an answer.) – Ken White Sep 14 '12 at 01:16
  • Ken - I found a VERY simple solution - posted as answer. But thanks for your help. – Vector Sep 14 '12 at 23:47

2 Answers2

5

My account has admin rights, but it hit me that I should try running DelphiXE as an admin – launch it with the ‘run as administrator’ option.

I got prompted ‘do you want to allow…’ – clicked yes and Delphi ran. Set up my process and hooked in and traced through my code - process names now visible and I can attach to my IIS process and debug in the Delphi Debugger.

I did not have to go through this step in my previous deployment, for whatever reason - but problem solved.

Vector
  • 10,879
  • 12
  • 61
  • 101
  • 1
    :-) That's why I asked about admin rights. It never occurred to me you wouldn't be running Delphi as an admin after that; I thought that was a given. Thanks for posting the solution; it may help someone later on. Don't forget you can accept this as the correct answer. It won't earn you rep, but it will let people know there's a solution here. (+1, BTW.) – Ken White Sep 15 '12 at 00:41
  • Well, as I said, I never had to specifically invoke 'run as admin' before - not at home where I have a similar environment, and not on my previous installation at work. – Vector Sep 15 '12 at 01:18
  • I also tried that with the MS Process Explorer (saw a link to it someplace on here - MS developer utility available for download, very cool) which is like task manager on steroids - it was also showing errors and 'process not accessible' before. But when I invoked 'run as admin' it showed everything. – Vector Sep 15 '12 at 01:21
  • I'm not an expert on Win 7 configuration by any means - but I think the 'enforce user rights' option is something that can turned on or off - that's what I culled from our CTO here - so maybe by default it is off, which is why I never had to deal with it. – Vector Sep 15 '12 at 01:27
  • 1
    Actually, UAC (User Access Control) is **on** by default in Windows 7. Someone had to have turned it off on your previous system. Win7 applies tightened security unless you tell it to do otherwise; even when running as an admin, with UAC on you get prompted to allow permission for things that affect the system in ways that might be unsafe. We're veering off here, though; it's now becoming a discussion that belongs on SuperUser instead of SO. – Ken White Sep 15 '12 at 02:06
  • You should not get into the habit of running the IDE elevated. If you do then one day you'll write code that works fine when you test it, but fails when deployed to be run by standard user. – David Heffernan Sep 15 '12 at 09:56
  • Thanks David - this is good advice. But my work is on a server application that runs on a Server 2008 R2 machine under an account that is fully permissioned to do anything and everything without any user intervention. – Vector Sep 16 '12 at 03:40
  • "We're veering off here" - true. But I think there must be a difference between Win 7 Enterprise and Win 7 pro here, which might explain the different behavior I have seen. My home machine and my previous installation I believe were Win 7 Pro - the new one is Enterprise. But I now run Ubuntu at home and use Python - so... – Vector Sep 16 '12 at 03:44
  • No difference in UAC/security between ent and pro. My point was don't form the belief that running IDE elevated is the norm. Perhaps you need to do it for this work. Fine. But don't do it when developing desktop apps. – David Heffernan Sep 16 '12 at 08:28
  • I've never had to do it before. Then again, I was never forced to work using a standard corporate OS image. – Vector Sep 17 '12 at 00:22
0

If you want to debug a 32 bit ISAPI dll on a 64 bit OS you can use the following process.

This assumes that you have followed other steps to allow 32 bit ISAPI dlls to work.

  1. Stop IIS

    net stop w3svc

  2. Start the 32 bit worker process in debug mode

    %SYSTEMROOT%\SysWOW64\inetsrv\w3wp -debug

  3. Attach to the w3wp in the debugger. As you noted you need to be running Delphi with elevated privileges for this to work.

Clint Good
  • 820
  • 6
  • 14