BoundsChecker is not working with Release Mode service application

DevPartner

DevPartner finds CPU hogs, plugs memory leaks, and cleans dirty code so your applications run faster and more efficiently.

BoundsChecker is not working with Release Mode service application

This question is answered

[Migrated content. Thread originally posted on 29 May 2012]

Today I purchased 99 days web edition but it is not working for my release mode service application.

I followed following steps to attach Bounds checker to my service executable.

To debug an application or service using Error Detection in an "Initialize and Wait" manner
1. Open the image you want to test inside the Error Detection application (BC.EXE).

2. Configure Error Detection to watch for the errors that interest you.

3. Select Wait for Process from the Program menu.
Error Detection initializes itself and displays a dialog box allowing you to cancel the session if desired.

4. Start your application as you normally would.
If you normally start your application via the Service Control Manager, then start it that way. Error Detection closes the dialog when your application starts.

5. Exercise your application, and then cause it to exit.


My application fails to stat whenever I attach Bounds checker to it. Can you please help me resolve this issue. Am I doing something wrong?


Regards,
Tarun
Verified Answer
  • For anybody else who might be reading here, we got together with the customer on Webex, and from what we saw there (a mixed mode service dying unexpectedly during startup), we recommended that he update to our latest build (10.5.1219.3 or 10.6.358.0). From what our Help Desk tells me, that resolved the problem with unexpected death, letting him proceed to other matters.

    The aforementioned builds have a number of stability fixes related to mixed mode native/managed applications, mostly related to how .NET uses the SuspendThread API function, and how .NET alters executable headers at load time.
All Replies
  • Depending on the options selected under Devpartner we can slow the application down enough that the timeout for the service control mamanger aborts the start.

    From http://support.microsoft.com/kb/824344

    When a service starts, the service communicates to the Service Control Manager how long the service must have to start (the time-out period for the service). If the Service Control Manager does not receive a "service started" notice from the service within this time-out period, the Service Control Manager terminates the process that hosts the service. This time-out period is typically less than 30 seconds. If you do not adjust this time-out period, the Service Control Manager ends the process and the attached debugger while you are trying to debug. To adjust this time-out period, follow these steps: •In Registry Editor, locate, and then right-click the following registry subkey:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control

    •Point to New, and then click DWORD Value. In the right pane of Registry Editor, notice that New Value #1 (the name of a new registry entry) is selected for editing.
    •Type ServicesPipeTimeout to replace New Value #1, and then press ENTER.
    •Right-click the ServicesPipeTimeout registry entry that you created in step c, and then click Modify. The Edit DWORD Value dialog box appears.
    •In the Value data text box, type TimeoutPeriod, and then click OK

    Note TimeoutPeriod is a placeholder for the value of the time-out period (in milliseconds) that you want to set for the service. For example, if you want to set the time-out period to 24 hours (86400000 milliseconds), type 86400000.
    •Restart the computer. You must restart the computer for Service Control Manager to apply this change.
  • I added the registry entry and set the timeout value to 24hours (86400000 milliseconds), but still i am getting timeout error.


    Services

    Windows could not start the SnapDrive service on Local Computer.



    Error 1053: The service did not respond to the start or control request in a timely fashion.



    OK


    I just set Memory leak analysis in the tool.

    Regards,
    Tarun
  • Well, perhaps we should see if we can connect to the service at all. Try turning off all DevPartner options altogether. In that case, BoundsChecker will be attached to the service, but the only things recorded will be process, thread and fiber start and stop notifications, and module and assembly loads and unloads. If this succeeds, then the process injection is working. From there, we then try activating various BC options to see which one(s) kill your service.

    Obviously, we shouldn't be killing your service...
  • Even after disabling all the options I am hitting the same error. Is there any other way to attach bounds checker to service application.

    I have installed visual studio on the machine. Is there any way to check the leaks after attaching the process in VS debugger?
  • Would it be possible for me to get ahold of a test copy of this, so I can see for myself what is happening?
  • that may not be possible.

    We can have a webex session where i can show you the problem that i am facing.
    I fall in IST time zone. Suggest a suitable time for the meeting. Also, if there is any local technical contact person who can help, then it would be great.


    Regards
    Tarun
  • We can do that. I am normally in the office Monday through Friday, 6am to 3pm, U.S. Eastern Time, though today I will have to leave a bit early. Our help desk can set up a webex, once they're in. Please e-mail Phil.Pimental@MicroFocus.com to get this set up.
  • I just sent a mail to Phil.Pimental@MicroFocus.com to setup WebEx.
  • Did you reboot the machine afteradding the registry key?
    Have you timed the amout of time before it gives the "failed to start" error?

  • For anybody else who might be reading here, we got together with the customer on Webex, and from what we saw there (a mixed mode service dying unexpectedly during startup), we recommended that he update to our latest build (10.5.1219.3 or 10.6.358.0). From what our Help Desk tells me, that resolved the problem with unexpected death, letting him proceed to other matters.

    The aforementioned builds have a number of stability fixes related to mixed mode native/managed applications, mostly related to how .NET uses the SuspendThread API function, and how .NET alters executable headers at load time.