Using ‘dbghelp.dll’ version ‘4.0.5’ error fixed in SQL Server 2012 SP1 CU6

If you use Extended Events you may have noticed that the ERRORLOG file gets bloated with messages like:

Using ‘dbghelp.dll’ version ‘4.0.5’

every time you query sys.dm_xe_sessions or read a file using Transact-SQL and the sys.fn_xe_file_target_read_file() table-valued function. This issue can be especially problematic on SharePoint 2013 installations, where a timer job queries Extended Events every 15 seconds to monitor the SharePoint SQL Server instance.

This has been fixed in SQL Server 2012 SP1 + CU6 which was just released today (  The specifics of this “feature” are contained in the following KB article (

13 thoughts on “Using ‘dbghelp.dll’ version ‘4.0.5’ error fixed in SQL Server 2012 SP1 CU6

  1. We are experiencing this error “Using ‘dbghelp.dll’ version ‘4.0.5’” running SharePoint 2013 and SQL 2008 R2 x64 SP2 (10.50.4000). Any idea how to eliminate this error?

    1. Hey Mark,

      There isn’t a fix for this on 2008 R2 yet, the only workarounds that you could do are, disable the Timer Job that is querying Extended Events every 15 seconds for the farm, change the time job to only poll the SQL Server at a more reasonable frequency like once per hour maybe, and the last one is to add a start up trace flag -T3656 to the SQL Server instance to pin the debugger dll into memory, but this may also have performance side effects that you should test. Hopefully at some point Microsoft will fix this in SQL Server 2008 and 2008 R2 with CUs later this year, but until then you can only try and work around the issue.

  2. CU10 for 2008R2 was released yesterday, but none of the included KBs is mentioning this problem.
    Anybody had the possibility to test though ?
    Thanks !

  3. I started seeing this message constantly as of last week. I upgraded from SQL Server 2008 R2 SP1 to SP@ and installed CU10 but I still get this message once a minute. How do I stop this from occurring? I’m not sure where to find the ‘Timer Job’.

    1. There is no published fix for 2008 or 2008 R2, this only applied to SQL Server 2012, so your only option on the older versions is to request a fix from Microsoft through Connect or product support, or to enable the trace flag at startup to pin the DLL to memory in the system.

    2. Hi Fred, out of curiosity, which SP 2013 CU version are you running? We are also seeing this behaviour with SQL 2008 R2 SP2, and SP 2013 March PU. I haven’t seen this issue with later CUs though, which is why I’m interested…

      1. The one I’m currently on is SQL Server 2008 R2 version 10.50.2500 and it just started happening here after we installed sharepoint foundation on the server to test it out.
        The one I was talking about in my last post was SQL Server 2008 R2 version 10.50.4297 (SP2 CU10).
        I changed jobs in between. Looking into Jonathan’s suggestions before enabling the trace flag as I noticed it wasn’t mentioned in CU11 either.

  4. Hi Jonatha,
    I am seeing this message filling logs and I have SQL Server 2008 SP3. Unfortunately none of the fix applied to my scenario, can you please point to any solution/reason. We also are not using Sharepoint

  5. Has anyone tried to address this issue in SQL 2008 (not R2) by enabling the trace flag at startup to pin the DLL to memory in the system as suggested by Jonahtan on 02/05/2014? Did it work?

Leave a Reply

Your email address will not be published. Required fields are marked *

Other articles

Imagine feeling confident enough to handle whatever your database throws at you.

With training and consulting from SQLskills, you’ll be able to solve big problems, elevate your team’s capacity, and take control of your data career.