Profile Windows Service

I have a profiler attached to a Windows service however it's only seems to profile the main service thread and not threads it spawns. As a result we can't profile any code we've written.

Is there a way round this? Are we doing something wrong?

Thanks

Comments

  • Hi Paul,

    let me start with the two most obvious questions just so we can disregard them -

    - Is the checkbox in the setup dialog which says "Profile Child Processes" checked?
    - If so, what appears in the combo box displaying "All Threads" by default on the main profiler UI. Are any of the processes you are wanting to see data for available for selection in there?

    If neither of these apply then it could be a bug and will need further looking into.

    Stephen
  • Hi,

    Yes that checkbox is checked. In that dropdown you refer to, there is a list of threads. However selecting any of them doesn't reveal anything. Most result in (Thread Blocked) in the main window or simply an empty window. However I know the service is working as it's doing what it should.

    Paul
  • I don't know whether this helps but here is some platform information...

    .NET 2.0 Windows Service
    Vista Business 64bit.

    Thanks again

    Paul
  • Hi Paul,

    one final check - is the display also set to showing CPU time and nothing changes?

    If looking for child processes it’s important that the environment isn’t changed to remove the variables set by the profiler when starting them or it won’t get attached.

    Stephen
  • Hi,

    Yes that is correct, I can see the CPU graph ticking away as the service works however I don't see any threads.

    I can send a screenshot if that would be useful.

    Thanks

    Paul
  • I have posted a screenshot here if it's useful....

    screenshot.png
  • Ah, I think I see what's going on here: the profiler can't find any debugging symbols for the service so it doesn't think that any methods have source code associated with them.

    You should be able to switch the Display drop-down to show all methods in order to see the missing methods: you'll see all the framework calls as well, so the results can get a little cluttered.

    To enable the profiler to identify methods with source, you'll need to put the .pdb files generated when you compiled it in the same directory as your service: they will show up in bold when the profiler can identify them.
    Andrew Hunter
    Software Developer
    Red Gate Software Ltd.
  • Hi,

    Yeah that seems to have got it working. :D

    Never even thought about that, always looking for the most complicated answer.

    Just need to buy our license now.

    Thanks again

    Paul
  • Hi,

    We seem to have encountered another issue while profiling the service. One of our threads uses the JET engine to connected to an excel file on a remote machine. Our service runs under a specific account and this account has all the relevant permissions. This all works fine. However when the profiler is attached we get an error when connecting to the file.

    The exception is not the most useful as it's just an "Unspecified error". I'm assuming it has something to do with permissions and the way the profiler stops and starts the service. Can you direct us in possible placed to look. We're making the assumption that when the service is restarted when the profiler is attached that it used the same account?

    <StackTrace>
    at System.Data.OleDb.OleDbConnectionInternal..ctor(OleDbConnectionString constr, OleDbConnection connection)
    at System.Data.OleDb.OleDbConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningObject)
    at System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup)
    at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
    at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
    at System.Data.OleDb.OleDbConnection.Open()
    at Communicator.Data.DataImport.ImportTempDB.Create() in C:\Documents\Visual Studio 2005\Projects\Communicator\v4\Communicator\Data\DataImport\ImportTempDB.cs:line 86
    at Communicator.Data.DataImport.Service.DataImporter.Import() in C:\Documents\Visual Studio 2005\Projects\Communicator\v4\Communicator\Data\DataImport\Service\DataImporter.cs:line 126</StackTrace>

    Here is a snapshot of the stacktrace pinpointing the the calls to the OLEDB objects.

    Thanks

    Paul
Sign In or Register to comment.