none
"DbgUiRemoteBreakin"

    问题

  • Just recently, I noticed that just about every running process - whether it be explorer.exe, winlogon.exe, or firefox.exe, has at least 1 (usually 6+) of the following thread: "ntdll.dll!DbgUiRemoteBreakin"

    From what I can gather, "ntdll!DbgUiRemoteBreakIn is used by the debugger to break in to a process, and the debugger assumes that the local address of DbgUiRemoteBreakIn matches the remote address of DbgUiRemoteBreakIn in the target process. Kernel32 is required to be at the same base address because there are a number of internal kernel32 routines that, similar to ntdll!DbgUiRemoteBreakIn, are used in cross-process thread injection."

    and, "the DebugBreakProcess API injects a remote thread into the address space of the target process."

    Having never seen this thread in all the years I've had a computer... it just seems odd that it would now be in almost every process, especially because I don't use or have any kind of debugger, and is active when no programs are running, right after the computer starts.

    If I understand correctly, "ntdll.dll!DbgUiRemoteBreakin" are remote threads being injected into the computer. That doesn't seem good.

    Any ideas on how to prevent it and/or figure out why it's happening?

    2018年1月25日 21:51

全部回复

  • Hi,

    How did you view these threads under each process if you are not debugging the programs?

    From my point of view, some programs like VS will also use API called DebugBreakProcess to trigger Breakpoint exception. 

    If it is a development issue. it is suggested that you can contact MSDN forum.

    The reason why we recommend posting appropriately is you will get the most qualified pool of respondents, and other partners who read the forums regularly can either share their knowledge or learn from your interaction with us.  Thank you for your understanding.


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    2018年1月26日 7:13
  • Process Explorer, which I've used for years.

    A response that I got on the StackExchange website about this issue, which seems likely, is that "having applications being 'debugged' mysteriously seems like you're infected by some kind of malware that injects itself into other programs (this way, the malicious behaviour appears to come from these normal programs)."

    I'm not sure if that's correct or not, but it's certainly not Process Explorer causing the issue.

    2018年1月26日 13:02
  • So what have you recently done?

    Install some programs, visit website which is not be trusted, will all lead to malware attack.

    What about boot into Safe Mode with networking and run Windows Defender to scan your system. After that, run the Windows Explorer to see if it has "ntdll.dll!DbgUiRemoteBreakin"


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    2018年1月29日 8:42
  • As far as I know, there are no programs or websites that caused this.

    I've restored the system to a week prior, and it was still there. I've scanned using Malwarebytes and Security Essentials, and they found nothing. I also started up in Safe Mode and they were there.

    I did manage to eliminate it though, and I did so by restoring the system to 1 month prior.

    The problem now is, after some testing I've found that it will only return if I install Windows Updates. This is unfortunate, and I can't imagine why this would happen, but the good news is that by not installing these Windows Updates I haven't seen the "ntdll!DbgUiRemoteBreakIn" process once.

    So it's certainly not a permanent fix, but until I can figure out why installing Windows Updates causes this, I've at least tempered the problem.

    2018年1月30日 19:06
  • Hi,

    On my test machine running windows 7 , I also see these threads:

    And I am sure that my computer doesn't install program like VS or Windbg, and it hasn't been affected by virus.

    Just don't worry about them.


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    2018年1月31日 10:21
  • I'm no longer concerned about them, because I don't have them (since I didn't install the Windows Update that caused them to appear).

    But aren't you curious why a thread that's normally associated with a debugger to break in to a process is active in all of your programs?

    This is what lsm.exe is supposed to look like:

    2018年1月31日 17:29
  • What updates you installed?

    Go to Control Panel> windows update> view update history.

    Please provide the  kb number so that I can reproduce the issue.


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    2018年2月2日 10:01
  • Sorry for the late reply! It's one (or more) of these:

    • KB4033342
    • KB2923545
    • KB3150513
    • KB971033
    2018年2月6日 15:25
  • Here is the result from my test:

    If I install the January updates kb4056897, kn4057440, kb 4055532, kb4074880, the problem will happen, and if i uninstalled all the updates, the problem disappear.

    So I look into these updates, and found that there is an update for .Net Framework, which is possible to debug the code or script in order to make sure code based on the .NET Framework integrates with any other code.

    Wow, It really take me long time to narrow down which updates lead to the problem.

    If my explanation did any help, please remember to mark it as an answer. Thanks in advance. 


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    2018年2月8日 9:16
  • I had the same problem on my computer also; oddly, eventually every instance of ntdll!DbgUiRemoteBreakIn was replaced by ntdll.dll!RtlDestroyHandleTable+0x270; In every instance, exactly, number for number. I was able to stop this debug issue by disabling debuggers via group policy. To accomplish this, remove all uses from the Policy "Computer Configuration/Windows Settings/Security Settings/Local Policies/User Rights Assignment/Debug programs". (if you do not have this option you must download Microsoft Security Compliance Manager 4.0; its the latest at the time of this post) Following that, your kernel is hardened and protected against debugging exploits. However, if there are any modifications detected, the kernel triggers a BSOD, so while you are less prone to modifications, hackers can trigger a BSOD fairly easily, and they did just moments before I posted the original comment here.

    While this was not an end all cure for my computer issues, it certainly helped in huge ways; I still have a debugger running inside Ntoskrnl, possibly via inline hooks and I suspect the notorious "Intel Management" as the origin for this problem. In my case, my hackers are using either SMM (System Management Mode) rootkit, Intel Management (most likely), or some other firmware as a backdoor... 

    I have 60-84 hooks in my IDT table, evenly distributed between each of my 4 cores. These HOOKS disappeared immediately after installing the latest Windows Spectre & Meltdown Security Rollups...  Uninstalling the windows updates resulted in the IDT hooks returning immediately. After the windows update, IDT hooks were replaced by a new hook in the INT2E System call handler, a hook which allowed User-Mode threads to transition into Kernel-Mode threads. All successful attempts at de-hooking this resulted in a BSOD. Similar to what happened to people using certain antivirus software after performing this Microsoft Meltdown/Spectre patch. Eventually whatever "protections" Microsoft's rollup update brought disappeared; The IDT hooks returned, the INT2E hook disappeared; And the ntdll!DbgUiRemoteBreakIn was replaced by ntdll.dll!RtlDestroyHandleTable+0x270! These two NTDLL calls are intimately related and both signify some kind of debugger exploit; They work around? Disable debugging. If only we could do the same at the hardware level. Intel & Motherboard manufacturers should include an option to disable debugging in the CPU via bios.

    Even with debugging disabled, Ntoskrnl is still hooked, and has a single KiDebugRoutine running.  

    These hooks I can remove in windows but even so, the hackers can still BSOD my system, which they did moments before I tried to post this. Here are more pictures of this exploit in action, courtesy of PCHunter (cutting edge anti-rootkit software)

    (unfortunately microsoft technet disallows new users from images and links)

    I've done numerous offline and online scans for virii and rootkits, all come up with nothing, suggesting I have a ring 2 rootkit in SMM (system management mode) or an exploited 'Intel Management' chip, (And possibly an exploited Intel firmware hub as well) which is most likely the case; Thus I will need to disable intel management entirely. This may require hard flashing the firmware, or to buy an aftermarket network card to circumvent Intels hard wired backdoor built into the motherboard. 

    On a side note; all attempts to use Process Explorer to access the threads individual stacks was no longer possible after disabling debugging. I guess debugging is what Process Explorer is all about.

    What are your thoughts on this?












    • 已编辑 tutudid 2018年2月13日 11:48
    2018年2月13日 5:31
  • I have a Windows 7 Home Premium machine with a fresh install a week ago.  2 days ago I noticed HDD activity every second with no programs running.  Through ProcMon and ProcExplorer I found a svchost.exe instance (DcomLaunch RegQueryValue 53f56307-b6bf-11d0-94f2-00a0c91efb8b) that had ntdll.dll using several ntdll.dll!DbgUiRemoteBreakin+0x50 thread(s).  One of these ntdll.dll!DbgUiRemoteBreakin+0x50 threads in particular was using alot of cycles.  

    After reading tutudid's post I checked other processes:

    All svchost instances have ntdll.dll!DbgUiRemoteBreakin+0x50 attached to them.  Explorer.exe as well.

    I have searched for the windows updates to remove that were listed by vivian_zhou:

    KB971033
    KB2923545
    KB3150513
    KB4033342

    The only update that applied to this machine was KB971033 and has since been removed.

    Windows 7 Home Premium does not have an available group policy editor that would allow for the Debug Programs disable suggested by tutudid.

    What exactly is going on with ntdll.dll!DbgUiRemoteBreakin+0x50 being attached to so many processes?

    How can it been diagnosed/disabled with in Windows 7 Home Premium?

    2018年2月15日 21:06
  • Update on the DbgUiRemoteBreakin:

    Installed the new SSD.

    Tried several attempts to configure each fresh Windows install. (Avoiding the malfunctioning USB, avoiding the USB port on the same USB controller as the malfunctioning USB port.  Using an external USB hub on a known working USB port.)  All had the same outcome as before;  The PnP svchost process was “polling” all SATA and USB drives on the system, every second.

     Completely unacceptable with the new SSD.

    What became apparent was the root of why the polling stared in the first place,  the newest Intel chipset driver.   The stock chipset drivers that shipped with Windows 7 did not cause any issues with the PnP subsystem.   It was only after the installation of the newest drivers (2011) that the “polling” issue arose.

    Chipset used in the laptop:  ICH9

    Drivers attempted to be installed: AHCI_Intel_9.6.2.1001_Win7x86x64

    Without these updated drivers installed the system is behaving very well and “polling” of USB and SATA drives is non-existant.

    This still does not explain what DbgUiRemoteBreakin is.  However, it seems that it is not something trying to “break in to the UI”.

    TL;DR:  If you are getting odd PnP issues; stick with the stock Microsoft chipset drivers.

    2018年3月10日 4:09
  • How did you view these threads under each process if you are not debugging the programs?

    For the sake of completeness, I'm going to respond to previous posters as well as explain my own situation in an omnibus message here, which I hope will be of help to some who have posted here and others that may develop this problem. This troubleshoot lasted almost 5 complete 12 hour+ days, so I've invested a tremendous amount of time to fix this. I realize this post is rather lengthy, but if you have the same problem as listed in this thread, I think you may be glad you read through it (otherwise, skip to the end).

    For the record, I used Process Explorer as well as Process Hacker, which is a more detailed and robust tool than Process Explorer.

    It can be obtained here

    I also made use of PC Hunter (an advanced process explorer/malware detection tool) as recommended by tutudid above (although I am not as technically proficient as he). Obtainable here (the developer's page is in Chinese).

    My problem is almost identical to tutudid's above; virtually all of my processes had various threads of ntdll!DbgUiRemoteBreakIn in them - what was more strange, is that I had just done a clean install of Win7 Ultimate, and noticed this only after performing all updates and installing various software packages.

    I have Eset, Malwarebytes, DrWeb and Avira on the system, all thorough scans showed no sign of malware, rootkits or anything else amiss. I scanned the system at least twice with each tool.

    Having read this thread, I performed a System Backup, then I began uninstalling and hiding various Windows Updates. First, these from Noles2, above:

    It's one (or more) of these:

    • KB4033342
    • KB2923545
    • KB3150513
    • KB971033

    It should be noted, that KB971033 is the infamous WAT activation update, which affects any copies of Windows 7 that have used an unauthorized activation hack to activate the product (ie. pirated). That may or may not have something to do with the problem, although I have no way of being able to tell that.

    Then, I proceeded to uninstall the following Updates from vivian_zhou's post, above:

    January updates kb4056897, kn4057440, kb 4055532, kb4074880, the problem will happen, and if i uninstalled all the updates, the problem disappear.

    These removals were all to no avail.

    I began uninstalling the most recent Windows Update packages that had been added since I had performed the clean install. For the record there were:

    • K84054981
    • K84054852
    • K83185319
    • K84075211
    • lnternet Explorer 11
    • KB3124275
    • Module linguistique d'Jnternet Explorer 11 fr-FR
    • Microsoft Windows French Spelling Package
    • Microsoft Windows English Spelling Package
    • Microsoft Windows Arabic Spelling Package
    • Microsoft Windows French Hyphenation Package
    • Microsoft Windows English Hyphenation Package
    • K83035132
    • K82912390
    • K83184143
    • K83181988
    • K83172605

    Upon reboot, I found that ALL instances of ntdll!DbgUiRemoteBreakIn had changed to ntdll.dll!RtlDestroyHandleTable+0x270 from startup, rather than some of them changing over time. At this point I thought I was on to something because of the posts above that indicated the whole problem lay in Windows Updates.

    I successively removed ALL Windows Updates and found that ntdll.dll!RtlDestroyHandleTable+0x270 persisted regardless. Next, I moved on to a clean-install and began installing Updates individually all the way up to current (including ALL of those referenced above, those listed by Noles2, those listed by vivan zhou and my own list). There was NO OCCURRENCE of either ntdll!DbgUiRemoteBreakIn nor of ntdll.dll!RtlDestroyHandleTable+0x270 .

    This led me to what proved to be a false conclusion: That the way in which one or more of these Windows Updates interacted with another software package or packages was to blame (indicating that perhaps many of us on this thread perhaps shared some software that was triggering the problem).

    Therefore, I began organizing to install all software in the order that it had originally been installed after the initial clean-install. Then, I realized that there were maybe 6-10 small software packages which had been installed and uninstalled prior to my noticing ntdll!DbgUiRemoteBreakIn in the first place, and that I wasn't entirely sure which those were.

    To get this information, I had to restore my system from backup to the point before I started uninstalling Windows Update. At which point, I reviewed this thread, where the other two 'solutions' were:

    ...disabling debuggers via group policy. To accomplish this, remove all uses from the Policy "Computer Configuration/Windows Settings/Security Settings/Local Policies/User Rights Assignment/Debug programs". (if you do not have this option you must download Microsoft Security Compliance Manager 4.0; its the latest at the time of this post) Following that, your kernel is hardened and protected against debugging exploits. However, if there are any modifications detected, the kernel triggers a BSOD, so while you are less prone to modifications, hackers can trigger a BSOD fairly easily...

    from tutudid above. I was not thrilled with this for one, I did not necessarily want to turn debugging off, nor did I wish to leave myself exposed to possibly easier BSODs as he details. Further, I did not look forward to Process Explorer no longer displaying individual stacks in threads as this would hamper future troubleshooting (requiring the re-application of debugging policies every time) and maybe even set back THIS troubleshoot, if disabling the debugging didn't completely "solve" the problem. (In the event, I will note that changing the policies and disabling debuggers DOES in fact stop the ntdll!DbgUiRemoteBreakIn and ntdll.dll!RtlDestroyHandleTable+0x270 threads, but I think only because those threads are being generated by a problem with debugging processes themselves - As tutudid explains, this does not even eliminate all instances of the problem, as he still has a bad thread and several hooks in the kernel which he attributes to other possible causes)

    and:

    the newest Intel chipset driver. The stock chipset drivers that shipped with Windows 7 did not cause any issues with the PnP subsystem. It was only after the installation of the newest drivers (2011) that the “polling” issue arose. Chipset used in the lapDrivers attempted to be installed: AHCI_Intel_9.6.2.1001_Win7x86x64 Without these updated drivers installed the system is behaving very well and “polling” of USB and SATA drives is non-existant.

    from RobertK6 , immediately above my post. I absolutely did NOT wish to revert to MS stock drivers for my SSDs because both speed and functionality of the SSD drives are lost without the Intel drivers, but I tested this to see what effect it would have (my chipset was ICH10, for the record).

    This proved not to be the cause as the ntdll!DbgUiRemoteBreakIn threads persisted in my case. I suspect that RobertK6's removal of the Intel drivers removed various functions (SMART, etc.) led to the hard drives polling less frequently and had nothing to do with ntdll!DbgUiRemoteBreakIn appearing in the threads of svchost process that was controlling HDD interactions. He does not definitively state above if the ntdll!DbgUiRemoteBreakIn threads stopped after removing the Intel drivers (I suspect they did not).

    In any event, at this point, I had to do another backup before embarking on re-installing all software in order to detect the problem, and while reviewing the list of applications installed and removed, I realized that early in the process of my original clean-install, there were a couple of tools I removed as redundant  and memory/CPU consumers and quickly forgot about. These included Zemana AntiMalware and SuperAntiSpyware. Before the next restore, I decided to re-install these two Anti-malware tools just to see if they detected anything different from the other tools already on the system (but I wasn't holding out much hope).

    It turned out that Zemana detected two suspicious registry keys as potential rootkit keys that the other Anti-malware & Antivirus packages had not detected. For the record:

    • HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\641BEDC85CEF37896C61BF8ABA7FDC635EAB6D1B\Blob

    and

    • HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\87C47CBB95638C2264392D88EEBCAE6AD9F84764\Blob

    Upon removal and reboot, the ntdll!DbgUiRemoteBreakIn threads and all other suspicious hooks were gone, obviously leading me to the conclusion that at least in my case, the problem was malicious rootkit registry keys (and whatever they were doing/vulnerabilities they were exploiting). This would explain at the very least, tutudid's experiences where after disabling debugging, he suffered BSOD hack attacks, as his system may have been under multi-pronged attack.

    Before you go through all the trouble of trying to isolate the problem with drivers or Windows Updates, I recommend exhausting the available tools for anti-malware/spyware/virus to see if one of them may detect suspicious registry keys, processes, applications or other which may be the actual cause of the problem.

    Zemana Antimalware is available here.

    Super Anti-Spyware is available here.

    Sophos Hitman Pro is available here.

    I hope this post will help some already on this list, and anyone who may come after with similar problems.

    *I am in no way affiliated with, nor do I necessarily endorse any of the products or software named in this article as guaranteed. As with all software, you use any of it at your own risk.





    2018年4月3日 10:46
  • Hi Noles2

    Have you found something more about this issue, as i have exactly the same problem you were asking about.

    I have tried to format partition, reinstalled Win7Pro and everything was fine, but after installing 1xx updates from Windows Update the problem come back again. Maybe i have installed some drivers before proceeding with WU, but i haven't installed any other software or surf the net.
    Indeed this is a really strange behaviour.

    Could you share some information about your system? (chipset, mobo, cpu ...)






    • 已编辑 Midmop 2018年5月14日 13:33
    2018年5月14日 13:27