Profile Windows Service
paulsmith
Posts: 9
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
Is there a way round this? Are we doing something wrong?
Thanks
Comments
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
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
.NET 2.0 Windows Service
Vista Business 64bit.
Thanks again
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
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
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.
Software Developer
Red Gate Software Ltd.
Yeah that seems to have got it working.
Never even thought about that, always looking for the most complicated answer.
Just need to buy our license now.
Thanks again
Paul
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