Dell Mobile Broadband Card Utility (DMBCU) Error 9999 - Networking, Internet, Wireless Forum - Networking, Internet, Wireless - Dell Community

Dell Mobile Broadband Card Utility (DMBCU) Error 9999

Networking, Internet, Wireless

Networking, Internet, Wireless
From Wi-Fi to wired Ethernet, mobile broadband to modems: it's all spoken here.

Dell Mobile Broadband Card Utility (DMBCU) Error 9999

  • Hi. I recently began having problems with DMBCU where it crashes at startup with a modal pop dialog box stating:

    Unknown application error:9999

    The modal dialog box appears on top of a window titled "MobiLink" where it has an action status of "Checking for components and license." (It's actually quite polite and suggests that I accept the terms "if you are happy to do so.")

    At some point the tool was working, but now it has stopped. I know it was working because it was whining about Activation, which I couldn't do until my ESN was added to the company's corporate contract with Verizon Wireless.

    One highlight of how I might have gotten myself in this mess is by Deactivating the Radio when DMBCU was working. I am very concerned that the combinatorics of The Switch, QuickSet and DMBCU have left the modem in a weird state. (though the modem responds to Queries form the device properties dialog box)

    3 other error messages that I have observed:

    1) During Startup, in Event Viewer System Log:
    DistributedCOM source registers:
    Unable to start a DCOM Server: {BE712FC5-5863-4C85-BD3D-8F3B7C4A6A7E}. The error:
    Happened while starting this command:
    C:\PROGRA~1\Dell\DELLMO~1\Phoenix.exe -Embedding

    Although that seemed stop when I set the Windows Services Telephony and Remote Access Connection Manager to Automatic startup.

    2) Running the Self-Diagnostic Utility NDPST.exe, when running the Network Diagnosis Phase the test fails, stating:

    WWAN Card Not Registered : 0

    All Software and Hardware Tests pass

    3) Corresponding to this test, an Event Viewer Application Log entry appears:

    Failed to open \\.\COM5 port with an Error: 170

    The error has a source of "Dell Mobile Broadband Card Utility" (which strictly speaking cannot be correct...).

    System Info:
    Dell Latitude D830
    Dell Wireless 5720 EVDO Rev A Broadband Card (Novatel E725)
    Intel 3945ABG (yes, I had the Intel PROset fiasco too)
    Bluetooth (which has no application radio controls)
    Vista, 32-bit, Enterprise
    Lot's of software
    Generally working with R159127 as the software package, which is the VZW version of the 5720 driver kits

    Uninstall / Reinstall. (1x, 2x, 3x, 4x....)
    Uninstall / Uninstall the device driver software / Reinstall (1x, 2x, ...)
    Reboots post re-install
    NPDST attempts (see above)
    Modem queries via the Modem Device dialog properties
    Disable User Authentication Controls in Vista, repeat uninstall, etc.
    Disable UAC and Firewall, repeat
    I have not tried with the virus scanning off
    My latest attempt: Remove Quickset, Conextant Drivers, UAC off, Firewall Off, hasn't helped.
    Attempting to direct dial via a Network Dialup connection to #777 fails with: The error code returned on failure is 678.

    Any ideas?
  • I have the same issue with a Dell XPS M1330, so far i tried reinstalling drivers, but no success.
  • I have been fighting the same issue on XPS M1330 with a Cingular card. Tried pretty much everything including hardware swap, with no result.
  • Just to update followers of this thread.
    I have an open case with Dell Support.  I have gone through Chat and Voice support on their Wireless Support group.  Still no luck (but they have tried less stuff than I have.)  Dell Support clearly is encountering this problem for the first time, since their internal knowledge bases are empty on this topic.
    Also, I am not sure how much further I will get, since my laptop shipped with WinXP (which would have been a good thing, since a colleague of mine retreated to WinXP in early December after the Intel PROset problems and Juniper VPN client support problems and he is working ok -- sorry, MIcrosoft), but my D830 is running Vista Enterprise for various reasons.  Despite the bare metal re-install from retail media (or Select Agreement media), I am now in a hole support-wise.
    I will continue to work on it.  My current work situation does not require EVDO for a couple of weeks. (ie. I am not traveling, that I know of).  My next guess is that the EVDO stopped working when the new Intel PROset software went in.
  • I too had a case open with Tech support about a week ago. Both Chat and voice, talked to several people, tried many things. My XPS M1330 came with Vista standard, so no excuse there.
    I need my 3G connection badly, so I hope I get a fix really soon.
  • Hi,
    I have the same problem with WinXP -- also tried reinstalling etc. but also still get the error 9999 -- was anyone sucessful in getting it fixed?

    Message Edited by jsfire on 01-12-2008 03:43 PM
  • I have same problem and have been trying everything to get this fixed. Dell support in Sweden basically said to reinstall Windows so not much help there. The problem seems to be the Dell Mobile Broadband Card Utility software.

    Have reinstalled the Dell Mobile Broadband Card Utility several times and have upgraded the modem firmware but nothing really fixes the problem. Keep getting the “Unknown application error:9999” as soon as I start the Dell Mobile Broadband Card Utility software. This happens in both win XP and Vista.

    Have found a temporary solution to get it working in XP:

    1. Disable Bluetooth Radio
    2. Right click “Dell Mobile Broadband Card Utility” on the start menu and select “Run as”. Then run program as local administrator.

    If I don’t disable the Bluetooth radio it will work but only for about 20-30 min then it crashes. Probably some port conflict between Bluetooth card and the Dell 5520 card.

    Another solution I have found under XP is to only install the drivers for Dell 5520 card and then set up a normal modem dial up connection through Windows. Problem is that I cannot change then modem configuration (e g use 3G or GSM) using this setup. Also it requires you to disable any PIN code on the sim card (so not good for security).

    Cannot get it to work at all under Vista. If anyone finds a proper solution please post…

    - - -

    Dell Latitude D830
    Dell Wireless 5520 Generic L Mobile Broadband Card (3G HSDPA) Minicard
    Intel 3945ABG
    Dell Wireless 350 Bluetooth Internal Card
    XP Pro and Vista Ultimate 32-bit

    Message Edited by nilsman on 01-13-2008 12:15 PM
  • I made some progress, at least a a work-around, in Vista: using "connect to" Dialup connection.
    After re-installing DMBCU, even trying to connect using directly the diap-up connection was not working, and Dell support was (one more time...) not very useful
    In the properties, mine had "ppp" as phone number.
    I replaced it with the string that ATT (my provider) recommends: "*99***1#" and now it works!
    Not sure I am getting the HSDPA 3G full speed, though, and I cannot find whre to put the string to force it.
  • I have been trying to debug, as Dell Technical Support seems to be unwilling to do so... I hope they read and will respond.
    I found some information that could be useful and lead somewhere toward a solution:

    Since sending it yesterday I have heard from the devs with this note:


    " Error 9999 is generated by Novatel's code when it looks like an object is not available (specifically license manager or the zeepe window object).


    They have dealt with this issue before, having asked our help before - and from their responses it looks like the customer was somehow blocking objects."


    There follows a whole bunch of detail, including the observation that:


    >> When the customer adds a Latitude D830/D820 (Dell factory image) to

    >> their domain (Admin Group) and runs the DMBCU application, they get

    >> the error message "Unknown application error: 9999".


    The application only generates this error message after putting a system onto the customer's domain.  Getting the system back out of the domain, the application runs fine again.


    Customer claims that it has to do something with his Active Directory, but due to about 2000 possible rules he needs to know which privileges the tool exactly needs to be run. <<


    I see that we provided a whole bunch of CLSIDs to check through, following which things went quiet (which we always have to assume means 'resolved').




    I don't know if any of this rings any bells in your situation, but I include it as being possibly relevant.


  • Alan.Guggenheim, thanks for that info.  As you have indicated, I too am coming to the conclusion that the problem has nothing to do with the driver software, despite support tech obsessions with uinstalling and reinstalling the driver software -- I don't blame them, Microsoft has trained the industry to operate that way...
    Here's my latest update:
    My last thread started when 2 of the "Microsoft Tues patch set" would not install, namely KB941644 and KB943899.  CBS logs were indicating error code 0x80004002, which is rather abiguous (like 9999), but better than the infamous 0x80004005.  The error was attached to this pearl:
      netcfg -e -c p -i ms_tcpip
    Inspecting the wired Ethernet interface (Broadcomm 5720 in a Dell D830), the properties listed NO PROTOCOLS. NO TCIP/IP of any type was listed.. (is that bad?  yup..)  Not sure how the configuration got in this state either.  I suspect one of the install sequences nuked 'em.  Curious, despite having NO TCP/IP protocol attached to the interface, TCP/IP was working just fine on the machine.  (I describe that fact as a problem.. it means what we are seeing in the configuration is not relevant to the configuration information that Vista is using...  Also no error messages anywhere that I could find).  A couple of attempts to run commands to restore lead me back to restoring the Vista config via running an "upgrade" from the Vista Enterprise DVD.  Following the "upgrade" of Vista on the existing Vista, the NIC properties returned and the patches installed!
    DMBCU still throws 9999 error.
    At this point, my VMware Worstation mouse tracking stopped working.  It was really bad, not just the usual CTRL-ALT release problems.  I had to competely uninstall VMware Workstation -- a reinstall/repair did not cut it.
    So, having this great success of getting the 2 patches to install under my belt, I started to unwind software touching any of the radio functions -- figuring maybe the TCIP/IP miss configuration that broke the KB installed broke DMBCU.  This would come to include:
      Dell Quickset
      Intel PROset
      Dell Mobile Broadband Client Utility
      Bluetooth software and drivers
    I also uninstalled software that added "derivative" network software, which included:
      VMware Workstation 6.0.2
      Symmantec Anti-Virus v10
    So with as little as possible and the NIC properties still looking good, I tried installing Dell Patch R159127 (yes, I've memorized it).
       No joy.
    Also, note at this point, with the uninstall of Symmantec and its NDIS/TDI parts, Vista is now bluescreening on shutdown.  In addition to the negative reinforcement of the immaturity of Vista and its necessary piles of software to use it, the bluescreening made shutdowns painfully long.  (Which my wife liked, since I would do chores around the house while I was waiting for the O/S to crash -- which it did consistently -- which I guess is a good thing...)   Once I reinstallled Symmantec, the bluescreens stopped.
    Also, I disabled Windows Search.  With the driver software installs and reboots, Search and Symmantic were beating up the hard drive with no purpose.  Plus, I get more chances to use my computer with search not sharing very nicely.
    All along through this process, I would try the DMBCU with no luck and consistent 9999 errors.  So, I'm going to conclude it's not a software conflict with other Microsoft, Dell or 3rd party software.  I was beginning to suspect the BIOS.  The arrival of A05 at the same time as the Intel PROset software corresponds closely to the death of DMBCU.  But based on the other notes in this thread it would appear not.  Dell Quickset should probably still be on the suspect list.
    Another observation:
    If one disables the radios with "The Switch", the start behavior is different.  The MLLauncher.exe never kicks off in the background.  DMBCU still throws the 9999.
    Yet another observation:
    If everything is installed, and one uninstalled Dell Quickset, DMBCU's icons go with it, even though the shortcuts are configured to get icon resources from here: C:\Program Files\Dell\Dell Mobile Broadband\MLLauncher.exe.
    So, I don't think it's the modem software at all.  I also think it's unlikely that an interaction between the DMBCU software and the underlying driver software.  It is very likely that it is in the COM layers that are part of the software stack and COM/DCOM permissions on Vista -- which would indeed involve the registry.
    Also, note that I'm working with Novotal E725 chipset that Dell calls the 5720 EVDO Rev A.   The firmware is set up for working with Verizon Wireless (sorry, I live in the NYC area).  Alan, since your set up is for a different carrier and different chipset, the problem has to be the application set up.
    As part of debugging the bluescreen, I've installed Windbg.exe, so my next try will be to load MLLauncher.exe and dmbcu into Windbg and run it to trace its calls.
    And oh yeah.   I have tried enabling the Administrator account and going that way.   No joy.
    And the laptop is NOT part of a domain, as the corporate domain's GPOs interact badly with Vista. 
  • A new observation:
    When the 802.11 WLAN interface (vs. the LAN or the WWAN), which on a Dell D830 is the Intel 3945ABG card, was not associated, because I was in an environment with WEP-protected access points that I had not yet entered the key for, the Dell Mobile Broadband SYSTRAY.EXE application did not indicate that it was MOBILE BROAD CONNECTION READY like it usually does / has since this process started.  As a matter of fact it did not display in the Vista System Tray at all.  Once I configured the WEP key for the local access point the SYSTRAY.EXE appeared.
    The observation is concerning because it seems to imply a linkage between the Intel PROset 3945ABG operation and the Dell Mobile Broadband 5720 card (aka Novotel E725), which seems unexpect to me, but would correlate chronologically with when the EvDO card stopped working, which was about when the Dell posted Intel's fixes and the new D830 BIOS (A05).
    But then I shouldn't be surprised since the wireless switch has a similar effect -- the SYSTRAY.EXE application does not seem to initialize.  (reported earlier in this thread)
    There is also the common linkage via Dell Quickset software, which I'm not sure how it is involved in this debugging.
  • Phoenix.exe is now consistently crashing.  Here's the debug summary:
    Unhandled exception at 0x763fb616 in Phoenix.exe: 0xC0000005: Access violation reading location 0x0000001b.
  • I FIGURED IT OUT!!!!!  :smileyhappy:
    2 pieces of data that I had not posted here yet.
    1) Output of Dependency Walker (DEPENDS.EXE) .  Alan, your comment about a missing dependency was the right direction. Problem was which one.  Using DEPENDS on DMBCU.EXE, PHOENIX.EXE and MLLAUNCHER.EXE shows an unexpected inclusion of IE libraries.  Most likely as a result of pulling in HTTPClient or an XML parser.  The use of OLE and COM and RPC libraries is also clear.  When I saw the IE dependency and looked at the configuration of the registered DLLs and Vista's WINSXS directories, I figured that was it. but no.
    2) Another trusty tool is WinDBG.EXE.  An oldy but a goody.  That did a better job of listing the load modules, since it kicked out debug output as the LoadModule commands were actually loaded, so the display showed the net-net, not necessary what resources Microsoft's linker may have thrown in the EXE header "for good measure."  When you run DMBCU.EXE under WinDbg.EXE and watch the EXE load and start to run the LoadModule debug statements kick out a whole set of libraries including:
    A dependency on Microsoft Office (yikes!), but what's a Zeep?  Well, on the file system was: C:\Program Files\Common Files\Zeepe Framework 7\ directories and the included files were indeed there.  The properties on the EXE and DLLs there indicate:
    MeadCo's Zeepe Rich Client
    Applications and DLLs are signed by Mead & Co.
    But everything looked OK.
    This evening while debugging an Apache HTTP Reverse Proxy server, I went to enable ieHTTPHeaders and what did I see in the IE Add Ons:  MeadeCo Zeepe add ons -- ALL DISABLED.  Ah Ha!  Enabled them.  Guess what: DMBCU now works!
    So, to check for this situation, do this:
    1. Launch Internet Explorer
    2. Using IE's menus, Select Tools->Manage Add-ons->Enable or Disable Add-ons
    3. In the 'Show' drop-down listbox, Select 'Add-ons that run without requiring permission'
    4. If any of the MeadCo Zeepe Add-ons are disabled, Enable THEM!
    5. Exit IE
    6. Restart IE and check that the configuration stayed.
    Try DMBCU!
    No, I do not know what disabled them.
  • This also fixed it for me! Thank you so much for figuring it out!!!!!!! :-))
  • Thanks !!!! Problem fixed on my XPS1330 !