none
DPM2010 Event ID 999: Error 19, Description "object reference is not set to an instance of an object"

    Question

  • Hi folks,

    I'm struggling with an error that's hit us "out of the blue" with the DPM MMC. We had a call lodged to restore content today and upon trying to access the Recovery tab within the DPM management console, it simply exits. It doesn't appear to crash in the strict sense of the definition, as there are no application crash events recorded in the event logs. Rather, the below exception is caught and the MMC simply closes with no further information.

    This is the error I get and it's from trying to access the Recovery tab within the MMC.

    <fatalserviceerror><__System><id>19</id><seq>0</seq><timecreated>23/05/2012 6:41:27 AM</timecreated>DpmThreadPool.cs<line>163</line><haserror>True</haserror><exceptiontype>NullReferenceException</exceptiontype><exceptionmessage>Object reference not set to an instance of an object.</exceptionmessage><exceptiondetails>System.NullReferenceException: Object reference not set to an instance of an object.
       at Microsoft.Internal.EnterpriseStorage.Dls.UI.RecoveryPage.RecoveryTreeNodeFactory.CleanupEmptyNodes(TreeView treeView, TreeNode startNode)
       at Microsoft.Internal.EnterpriseStorage.Dls.UI.RecoveryPage.RecoveryBrowseTab.RenderTreeView()
       at System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
       at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)</exceptiondetails></fatalserviceerror>

    Has anyone see this "object reference is not set to an instance of an object" error before and managed to resolve it?

    I couldn't tell you what may have happened as we don't get many calls to run restores on account of having other protective features enabled in front of DPM. It's literally been months since we've needed to run a hard restore for anything, meaning there's months of Windows patches that have taken place in between, though I don't expect this is necessarily the issue or else it would be more widespread.

    What I'm struggling with now is that I'm not aware of any other locations or any other means for enabling/finding more detailed logging.

    Cheers,
    Lain

    • Modifié Lain Robertson mercredi 23 mai 2012 07:17 Corrected the title.
    mercredi 23 mai 2012 07:16

Réponses

  • Second attempt at closing this call off.

    We've decided we have no other choice than to absorb not having backups for a week and have rebuilt the Storage Server and re-installed DPM 2012 (which we upgraded from 2010 in a desperate attempt to resolve this issue).

    In a way, this at least again lends support to the notion it wasn't a .NET 4 issue. That's not a guarantee, of course, but it seems likely.

    The only real difference we had in the end - before this rebuild, was that the replicase and symbolic links (or junctions) all still existed, which brings me back to the though that DPM really could do with some kind of consistency checker that can reconcile what's in the database versus what exists on the disks.

    Nevertheless, we're hoping the problem is resolved now in a permanent fashion - we should know by the end of the week once replication's done, so this case is closed.

    Cheers,
    Lain

    mercredi 13 juin 2012 07:22

Toutes les réponses

  • Closing this issue as there's just no information/logging to work with. We're uninstalling DPM and re-installing it as a "workaround". Hopefully this resolves the issue.

    Cheers,
    Lain

    jeudi 24 mai 2012 00:42
  • A complete re-installation yielded no joy. We're still stuck with the same behaviour above.

    I thought I had mentioned this in the original post, but I hadn't, that in addition to the MMC crash, the Reporting Services tab was also "broken" insofar as it couldn't contact the Reporting Services component. As expected, it was actually an issue with the Reporting Services component itself, which had also stopped working after the patch cycle, though I was able to resolve this using the supportedRuntime element referenced here.

    This leads me to wonder if there's more .NET 4 havoc that's been wrought by patches from the last three months. So, I guess that's the line I'll be pursuing though I'm not entirely sure where to start.

    Cheers,
    Lain

    jeudi 24 mai 2012 01:34
  • Well, I've exhausted the .NET 4 school of thought. That's not the issue either.

    I had a read of this article, and while I do have the same UI crash issue, I don't have a problem with computers that have names longer than 15 characters. But it did get me wondering if there are any circumstances under which  the contents held under the "Microsoft DPM\DPM\Volumes" can cause the client to get upset and fail. For example, if there is some kind of discrepancy. It would be nice if there was a consistency checker that would validate this for you.

    In any case, I'm back looking at the product itself and wondering what's going on. Certainly, none of the prerequisites seem to be the cause of the issue. This was somewhat reinforced with having a new installation performed minus .NET 4 and still having the UI crash. The main point to note was that the prior uninstallation used the option of leaving the disk content in-place (since we can't well afford to replicate 4TB back over the WAN again).

    If anyone has any ideas or knows how to access an increased level of logging, please don't be afraid to speak up, as all I have is hunches, educated guesswork and a very loose process to work with so far.

    Cheers,
    Lain

    jeudi 24 mai 2012 07:41
  • Second attempt at closing this call off.

    We've decided we have no other choice than to absorb not having backups for a week and have rebuilt the Storage Server and re-installed DPM 2012 (which we upgraded from 2010 in a desperate attempt to resolve this issue).

    In a way, this at least again lends support to the notion it wasn't a .NET 4 issue. That's not a guarantee, of course, but it seems likely.

    The only real difference we had in the end - before this rebuild, was that the replicase and symbolic links (or junctions) all still existed, which brings me back to the though that DPM really could do with some kind of consistency checker that can reconcile what's in the database versus what exists on the disks.

    Nevertheless, we're hoping the problem is resolved now in a permanent fashion - we should know by the end of the week once replication's done, so this case is closed.

    Cheers,
    Lain

    mercredi 13 juin 2012 07:22