Windows 7 Event Viewer Error "Failed to connect to the driver: (-2147024894)"

---

Алексей Д.1 schrieb:
I fast fix error drive start whithout copy file or edit regedit:
MKLINK "C:\Windows\System32\drivers\dbx.sys" "C:\Windows\System32\drivers\dbx-canary.sys"

It's work end drive normal start:
The file is signed and the signature was verified: C:\Program Files (x86)\Dropbox\Client\Dropbox.exe
Certificate match for file: C:\Program Files (x86)\Dropbox\Client\Dropbox.exe
Accepting connection from client: C:\Program Files (x86)\Dropbox\Client\Dropbox.exe

Hi,

How you did it? Please explain us the steps.

Thanks

Vik

Hi to everyone:

I resolve this download the version:

https://www.dropbox.com/downloading?build=14.4.19&plat=win&type=full

14.4.19

I have a re-build machine whit this details:

Processors
-------------------------------------------------------------------------

Number of processors 1
Number of threads 2

APICs
-------------------------------------------------------------------------

Processor 0
-- Core 0
-- Thread 0 0
-- Core 1
-- Thread 0 1

Timers
-------------------------------------------------------------------------

ACPI timer 3.580 MHz
Perf timer 3.085 MHz
Sys timer 1.000 KHz

Processors Information
-------------------------------------------------------------------------

Processor 1 ID = 0
Number of cores 2 (max 2)
Number of threads 2 (max 2)
Name Intel Core 2 Duo E8500
Codename Wolfdale
Specification Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz
Package (platform ID) Socket 775 LGA (0x0)
CPUID 6.7.A
Extended CPUID 6.17
Core Stepping E0
Technology 45 nm
TDP Limit 65.0 Watts
Core Speed 1995.0 MHz
Multiplier x Bus Speed 6.0 x 332.5 MHz
Rated Bus speed 1330.0 MHz
Stock frequency 3166 MHz
Instructions sets MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, EM64T, VT-x
L1 Data cache 2 x 32 KBytes, 8-way set associative, 64-byte line size
L1 Instruction cache 2 x 32 KBytes, 8-way set associative, 64-byte line size
L2 cache 6144 KBytes, 24-way set associative, 64-byte line size
Max CPUID level 0000000Dh
Max CPUID ext. level 80000008h
Cache descriptor Level 1, D, 32 KB, 1 thread(s)
Cache descriptor Level 1, I, 32 KB, 1 thread(s)
Cache descriptor Level 2, U, 6 MB, 2 thread(s)
FID/VID Control yes
FID range 6.0x - 9.5x
Max VID 1.288 V

Temperature 0 37 degC (98 degF) (Core #0)
Temperature 1 34 degC (93 degF) (Core #1)
Clock Speed 0 1995.02 MHz (Core #0)
Clock Speed 1 1995.02 MHz (Core #1)

Chipset
-------------------------------------------------------------------------

Northbridge Intel Q45/Q43 rev. 03
Southbridge Intel 82801JB (ICH10) rev. 02
Memory Type DDR3
Memory Size 8 GBytes
Channels Dual, (Symmetric)
Memory Frequency 532.0 MHz (5:8)
CAS# latency (CL) 7.0
RAS# to CAS# delay (tRCD) 7
RAS# Precharge (tRP) 7
Cycle Time (tRAS) 20
Row Refresh Cycle Time (tRFC) 86
Command Rate (CR) 2T
Host Bridge 0x2E10

Memory SPD
-------------------------------------------------------------------------

DIMM # 1
SMBus address 0x50
Memory type DDR3
Module format UDIMM
Manufacturer (ID) (00000000000000000000)
Size 2048 MBytes
Max bandwidth PC3-10700 (667 MHz)
Part number V01D3L82GB26826813
Manufacturing date Week 16/Year 15
Number of banks 8
Nominal Voltage 1.50 Volts
EPP no
XMP no
AMP no
JEDEC timings table CL-tRCD-tRP-tRAS-tRC @ frequency
JEDEC #1 5.0-5-5-14-19 @ 380 MHz
JEDEC #2 6.0-6-6-17-23 @ 457 MHz
JEDEC #3 7.0-7-7-20-27 @ 533 MHz
JEDEC #4 8.0-8-8-22-30 @ 609 MHz
JEDEC #5 9.0-9-9-24-33 @ 666 MHz
JEDEC #6 10.0-9-9-24-33 @ 666 MHz

DIMM # 2
SMBus address 0x51
Memory type DDR3
Module format UDIMM
Manufacturer (ID) (00000000000000000000)
Size 2048 MBytes
Max bandwidth PC3-10700 (667 MHz)
Part number V01D3L82GB26826813
Manufacturing date Week 16/Year 15
Number of banks 8
Nominal Voltage 1.50 Volts
EPP no
XMP no
AMP no
JEDEC timings table CL-tRCD-tRP-tRAS-tRC @ frequency
JEDEC #1 5.0-5-5-14-19 @ 380 MHz
JEDEC #2 6.0-6-6-17-23 @ 457 MHz
JEDEC #3 7.0-7-7-20-27 @ 533 MHz
JEDEC #4 8.0-8-8-22-30 @ 609 MHz
JEDEC #5 9.0-9-9-24-33 @ 666 MHz
JEDEC #6 10.0-9-9-24-33 @ 666 MHz

DIMM # 3
SMBus address 0x52
Memory type DDR3
Module format UDIMM
Manufacturer (ID) (00000000000000000000)
Size 2048 MBytes
Max bandwidth PC3-10700 (667 MHz)
Part number V01D3L82GB26826813
Manufacturing date Week 16/Year 15
Number of banks 8
Nominal Voltage 1.50 Volts
EPP no
XMP no
AMP no
JEDEC timings table CL-tRCD-tRP-tRAS-tRC @ frequency
JEDEC #1 5.0-5-5-14-19 @ 380 MHz
JEDEC #2 6.0-6-6-17-23 @ 457 MHz
JEDEC #3 7.0-7-7-20-27 @ 533 MHz
JEDEC #4 8.0-8-8-22-30 @ 609 MHz
JEDEC #5 9.0-9-9-24-33 @ 666 MHz
JEDEC #6 10.0-9-9-24-33 @ 666 MHz

DIMM # 4
SMBus address 0x53
Memory type DDR3
Module format UDIMM
Manufacturer (ID) (00000000000000000000)
Size 2048 MBytes
Max bandwidth PC3-10700 (667 MHz)
Part number V01D3L82GB26826813
Manufacturing date Week 16/Year 15
Number of banks 8
Nominal Voltage 1.50 Volts
EPP no
XMP no
AMP no
JEDEC timings table CL-tRCD-tRP-tRAS-tRC @ frequency
JEDEC #1 5.0-5-5-14-19 @ 380 MHz
JEDEC #2 6.0-6-6-17-23 @ 457 MHz
JEDEC #3 7.0-7-7-20-27 @ 533 MHz
JEDEC #4 8.0-8-8-22-30 @ 609 MHz
JEDEC #5 9.0-9-9-24-33 @ 666 MHz
JEDEC #6 10.0-9-9-24-33 @ 666 MHz

The machine is very old.

Maybe some old isntructions are out from thye new binaries.

Hi,

the error is still present with the latest DB version (16.4.30). I did some research for the error code -2147024894, which if converted to a 32 bit hexadecimal value results to 0x80070002. I found a registry for those values at Symantec, and it revealed it to be of type "Win32 Error Codes for ADSI". Additional Research at Microsofts Developer Network showed a bit more details: Looks like it is the error code for a failed LDAP request (LDAP_NO_SUCH_OBJECT). So the questions seems to be: Why does DB do LDAP (or Active Directory with Windows) requests? And will the observed error within Event Viewer only happen with Windows PCs that are not members of an Active Directory?

I did some further investigation and figured out that the error was safely reproducible every time the "DbxSvc" service starts. Hence inside service manager I stopped this service and started Wireshark and SysInternal's Process Monitor in order to see what happens after I have started the service again (this way provoking the error to happen once more).

These are the results: During service start no network activity could be observed. All file and registy access of the process named "DbxSvc.exe" didn't reveal any hints that something went wrong (no results more critical (but normal) than "NAME NOT FOUND" or "BUFFER OVERFLOW" with registy access or "FILE LOCKED WITH ONLY READERS" with file access).

Only the last registry access asks for the value of "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\WMR\Disable", probably to check if errors should be reported to Microsoft.

Hence, it's still a mystery why this error happens. This thread says, that this service isn't even needed to use DB:

"You noted sync still appears to work correctly without this service however should you encounter any sync issues with the service removed it will limit our ability to resolve the issue."

Btw: The OP reported about ESENT messages he believes cause a recovery from the error state. With my PC I also see these ESENT messages but they happen at other times than the DbxSvc.exe error - hence, I believe they are independent from each other.

Orion:  Did you get this information, regarding Dropbox not fixing the error, while on one of your time travelling escapades or is this December 2016/January 2017 information?  It seems odd that Dropbox are happy to accept a bug in their software albeit afairly harmless one.

Loopback:  As the OP of this thread I thank you for your input and the research you have done.  I assumed, incorrectly, that the ESENT items in the Event Viewer report related to the Dropbox error as they followed immediately afterwards, mentioned 'recovered' and Dropbox worked correctly afterwards so it was just coincidence.

Has anyone other, than Алексей Д.1, tried his MKLINK workaround?  If it works it would at least tidy up the Event Viewer reports even if it does not actually fix the bug.

Yes, Luke from Dropbox support told me directly.  The issue doesn't prevent syncing, so it won't be fixed.

I tried the MKLINK workaround Алексей Д.1 posted and the errors were still logged.  So I uninstalled Dropbox - no more errors!

---

orion44 wrote:
Dropbox support has informed me they will not be fixing this error.

---

Nor will they tell us what the issue is!

Maybe driver dbx and service dbxsvc are key functions needed for strategic "Project Infinite"?

See Dropbox filesystem integration: an overview and Going deeper with Project Infinite.

If so, when not using Infinite, can service DbxSvc simply be stopped and deactivated in Service Manager without any negative impact on standard sync behaviour between web store and local copy?

Hi All,

I contacted Dropbox Technical Services via the webform to get confirmation of Dropbox's policy on this bug but just got the standard automated response containing a link to FAQs - useless and pointless regarding this particular issue. 

Mat-Glock reflects many users' opinion of Dropbox if this is their attitude.  I may be only a free version user, Mat paid for his and certainly deserves a better standard of customer care, but free version users also deserve better service and are potential paying customers when they like what they get.  Any software developer who is prepared to leave a bug does not deserve to be trusted, what other bugs might they leave unaddressed in the future?

It is also telling that very little interest has been shown in this thread by Dropbox personnel who might have injected some useful input.

Maybe they'll listen if more people submit help requests to Dropbox Technical Services .  This forum just serves as a black hole for support requests, Dropbox employees don't browse it or just don't care.

---

Loopback wrote:

Maybe driver dbx and service dbxsvc are key functions needed for strategic "Project Infinite"?

 

See Dropbox filesystem integration: an overview and Going deeper with Project Infinite.

 

---

That would be my best guess, too. They need this service present in the installation package because they're still developing it, even though it just fails for now. And they'd rather spend more time in the service's development than in removing it from "production" deployments.

Otherwise, this whole mess would be totally outrageous. It still is very unprofessional, they're installing a service that doesn't work and a file system driver that doesn't load at all, there's no doubting it by now.

---

vkapartzianis wrote:

That would be my best guess, too. They need this service present in the installation package because they're still developing it, even though it just fails for now. And they'd rather spend more time in the service's development than in removing it from "production" deployments.

---

... since service DbxSvc seems to be useless, and Dropbox runs perfectly without it, I stopped it and set its state to DISABLED. No Event Viewer errors any more :slight_smile:

Since any update of Dropbox client software will probably re-establish DbxSvc service to be started automatically, here is my solution to put it back to and keep it in disabled state automatically:

Create some folder (e.g. "C:\DbxSvcWatchDog"). Inside this folder create a batch file named "dbxsvcdisable.cmd" with the following contents:

@echo off
sc stop DbxSvc
sc config DbxSvc start= disabled

Right click file "dbxsvcdisable.cmd" and create a link to it inside the same folder. Rename this link to "dbxsvcdisable" (this is the link's name as shown within Windows Explorer; a "DIR" command at the command prompt will show the link's name to be "dbxsvcdisable.lnk").

Edit the properties of the link, set its execution mode to "minimized" and activate the "run as administrator" feature via the Advanced... button. The last step is important, because you need administrative rights to execute the script (which provokes an UAC message you have to confirm in order to allow execution).

Inside the folder create a second batch file (a watchdog that constitutes a wrapper around the stop script) named "dbxsvcwd.cmd" with the following contents:

@echo off
SETLOCAL ENABLEDELAYEDEXPANSION
for /f "tokens=3" %%i in ('sc qc DbxSvc ^| find "START_TYPE"') do (
	if NOT "%%i"=="4" (
		call dbxsvcdisable.lnk
	)
)

Right click file "dbxsvcwd.cmd" and create a link to it inside the same folder. Rename this link to "dbxsvcwd". Edit the properties of the link and set its execution mode to "minimized". Move this link file to the startup folder for all users (C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup).

Now every time Windows starts the wrapper is executed. It checks if the state of service DbxSvc is still set to disabled. If so nothing else happens. Only in the case that the service's state has changed from disabled to some other state (e.g. via an update of the dropbox client software), the stop script is run. You notice this via the UAC window you have to confirm for execution.

It's stupid as problem persists and users need to figure solution themselves, shame on Dropbox.

I will probably use loopback's solution as this **bleep**ty service keeps hanging my PC once a week

I tried Loopback's get around - manually disabling the dbxsvc service works until the next program update as he explained but I tried the batch file approach to avoid having to disable the dbxsvc service again after a program update but, unfortunately, it did not work for me so I had to disable the service again.  Perhaps I made an error somewhere along the line so I will have to check back.

Hi,

the "wrapper" script doesn't run permanently but only once after Windows Login (Startup). Hence, if the DB client software is updated, DbxSvc service is started again (start type is set to automatic) and doesn't stop until you at least logoff and logon again (e.g. via Windows (Re-)boot).

Loopback

Hi Loopback,

 Thanks for explaining that - I understand now.

Hi all,

Just dropping in here to say thank you for your amazing research and persistence trying to get this issue fixed. I've been experiencing the same problems for a while now, but could never trace it back to Dropbox until today. Unlike a lot of you, my PC just completely freezes and becomes unusable, instead of simply throwing an error in the Event Log. 

While this does seem like a pretty critical issue, I'm baffled by the fact that Dropbox apparently don't want to fix this issue, if I understand the previous replies in this thread correctly. I will also email support with my findings, hoping they'll reconsider, but I highly doubt it.

Anywho, thank you all again for the amazing research so far! I'll keep you posted about my correspondence with Dropbox Support.

Same problem for me and when I have seen the number of reads for this thread, I thought that's unbelievable they do not fix it from Dropbox side!

Just an idea, but did somebody check if the missing file(s) (dbx.sys and others?) could be found in a previous Dropbox installation? If so why not extracting them and make them available to download via Dropbox ;-). Users then could manually put them into the folder where Windows checks for them ...