none
There is a problem with my restored SharePoint databases - They appear to be corrupt, I am unable to attach to any SQL instance RRS feed

  • Question

  • I have a DPM 2012 SP1 server set up and just configured protection for my SharePoint 2013 farm. DPM created the initial replica and all future recovery points have been created successfully. However, when I recover any of the databases (content or config) to a network folder and try to attach the MDF to any instance of SQL server, I immediately (after browsing for and selecting the MDF file) get the following error in SQL Management Studio:

    Paths that begin with \\?\GlobalRoot are internal to the kernel and should not be opened by managed applications. (mscorlib)
    
    ------------------------------
    Program Location:
    
       at System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength)
       at System.IO.Path.GetDirectoryName(String path)
       at Microsoft.SqlServer.Management.SqlManagerUI.AttachDatabaseData.PrimaryFile.PopulateAssociatedFiles(String primaryFilePath)
       at Microsoft.SqlServer.Management.SqlManagerUI.AttachDatabaseData.PrimaryFile.PopulatePrimaryFileData(String primaryFilePath)
       at Microsoft.SqlServer.Management.SqlManagerUI.AttachDatabaseData.PrimaryFile..ctor(SqlManagementUserControl parent, CDataContainer dc, String fullPath, String databaseOwner, ServerConnection connectionInfo)
       at Microsoft.SqlServer.Management.SqlManagerUI.AttachDatabase.AddPrimaryFile(String fullPath, String fileName)
       at Microsoft.SqlServer.Management.SqlManagerUI.AttachDatabase.buttonBrowse_Click(Object sender, EventArgs e)
       at System.Windows.Forms.Control.OnClick(EventArgs e)
       at System.Windows.Forms.Button.OnClick(EventArgs e)
       at System.Windows.Forms.Button.WndProc(Message& m)
       at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
       at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
       at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
       at System.Windows.Forms.UnsafeNativeMethods.SendMessage(HandleRef hWnd, Int32 msg, IntPtr wParam, IntPtr lParam)
       at System.Windows.Forms.Control.SendMessage(Int32 msg, IntPtr wparam, IntPtr lparam)
       at System.Windows.Forms.Control.ReflectMessageInternal(IntPtr hWnd, Message& m)
       at System.Windows.Forms.Control.WmCommand(Message& m)
       at System.Windows.Forms.Control.WndProc(Message& m)
       at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
       at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
       at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
       at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
       at System.Windows.Forms.UnsafeNativeMethods.CallWindowProc(IntPtr wndProc, IntPtr hWnd, Int32 msg, IntPtr wParam, IntPtr lParam)
       at System.Windows.Forms.NativeWindow.DefWndProc(Message& m)
       at System.Windows.Forms.Control.DefWndProc(Message& m)
       at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
       at System.Windows.Forms.Control.WndProc(Message& m)
       at System.Windows.Forms.ButtonBase.WndProc(Message& m)
       at System.Windows.Forms.Button.WndProc(Message& m)
       at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
       at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
       at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
       at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
       at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
       at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)

    As a test I have protected a non-SharePoint SQL database on a different server, restored to a folder and I am able to attach it just fine. I am checking event logs for VSS or DPMRA errors on both the SharePoint WFE and the SQL server but there is nothing to indicate a problem. Regarding the error when attaching to an SQL instance, I can't find much info about it other than it might be related to a problem with VSS paths?

    Any ideas?

    Edit: I have also ran consistency checks, and also removed the protection group and data from DPM entirely and recreated it. I still get the error with the restored database files.



    • Edited by tpullins Thursday, October 3, 2013 5:38 PM content
    Wednesday, October 2, 2013 5:30 PM

Answers

  • Hi,

    We had a customer open a support incident for this and it seem to be an issue with Product studio.

    Snip from SQL group engineer who investigated - external content will be published by SQL group.

    <snip>

    Problem Description:-
    You are trying to attach a database from SQL Server 2008 R2 Management studio by using the Attach wizard, During the attach process management studio reports an error and relative stack for the same is as below

    Error:

    Paths that begin with \\?\GlobalRoot are internal to the kernel and should not be opened by managed applications. (mscorlib)
    ------------------------------
    Program Location:
       at System.IO.Path.NormalizePathFast(String path, Boolean fullCheck)
       at System.IO.Path.NormalizePath(String path, Boolean fullCheck)
       at System.IO.Path.GetDirectoryName(String path)
       at Microsoft.SqlServer.Management.SqlManagerUI.AttachDatabaseData.PrimaryFile.PopulateAssociatedFiles(String primaryFilePath)
       at Microsoft.SqlServer.Management.SqlManagerUI.AttachDatabaseData.PrimaryFile.PopulatePrimaryFileData(String primaryFilePath)
       at Microsoft.SqlServer.Management.SqlManagerUI.AttachDatabaseData.PrimaryFile..ctor(SqlManagementUserControl parent, CDataContainer dc, String fullPath, String databaseOwner, ServerConnection connectionInfo)
       at Microsoft.SqlServer.Management.SqlManagerUI.AttachDatabase.IsSelectedFileValid(BrowseFolder dlg
      
      
      
     The restriction of not allowing Kernel object names during directory lookup has been added in the .Net layer and when the control from management studio gets passed on to traverse the location of the LDF file from DBCC CHECKPRIMARYFILE output we are hitting this restriction.


    The DPM application internally uses AUTORECOVERY option during backup. This instructs SQL Writer to take a snapshot of the database and then re-attach them back to SQL Server from the backup location so that it can reduce the recovery timeframe in case if this backup has to be restored. Since VSS internally maps a Shadow copy of the path the relative path gets converted to \\?\GlobalRoot

    Example: Given the path:  E:\Vol_P\UserDB\MSSQL\Data\DBNAME.mdf changes to \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy####\MSSQL\Data\DBNAME.mdf

    Since we are attaching the database from this shadow copy path this path gets overwritten in to the header of the MDF File and when management studio internally fires DBCC CHECKPRIMARYFILE to get the actual path of the files we end up in this situation.

    As a workaround measure you can keep the MDF and LDF file in a single location during attach process so that management studio doesn’t need to traverse the path. Apart from this you can always use a TSQL Statement “CREATE Database FOR Attach” to attach the databases.
    >snip<

     


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    • Marked as answer by tpullins Monday, October 14, 2013 7:44 AM
    Wednesday, October 9, 2013 3:43 PM
    Moderator

All replies

  • I'm at a loss, I don't know where to go from here. I have updated and rebooted my DPM and SharePoint Web/SQL servers. Recovery points are being created without issues, event logs do not indicate any problems, but the problem with recovering to a network folder and attaching to SQL is still there.
    Tuesday, October 8, 2013 5:21 AM
  • Hi,

    SQL backups use autorecoverable snapshots and the sql writer records metadata about how the db was last mounted.  I have heard that simply copying the files to a different location or volume will allow them to be mounted.  Please try that.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, October 9, 2013 4:10 AM
    Moderator
  • Hi Mike, 
    I assume you mean copying the recovered database files (and not the source database files on the SharePoint SQL server) to a different volume/location? I have done this by copying from the network folder DPM restored to, to an SQL server on the network before attaching. I've also tried restoring the databases directly to another instance of SQL and it fails.

    Wednesday, October 9, 2013 5:47 AM
  • Hi,

    We had a customer open a support incident for this and it seem to be an issue with Product studio.

    Snip from SQL group engineer who investigated - external content will be published by SQL group.

    <snip>

    Problem Description:-
    You are trying to attach a database from SQL Server 2008 R2 Management studio by using the Attach wizard, During the attach process management studio reports an error and relative stack for the same is as below

    Error:

    Paths that begin with \\?\GlobalRoot are internal to the kernel and should not be opened by managed applications. (mscorlib)
    ------------------------------
    Program Location:
       at System.IO.Path.NormalizePathFast(String path, Boolean fullCheck)
       at System.IO.Path.NormalizePath(String path, Boolean fullCheck)
       at System.IO.Path.GetDirectoryName(String path)
       at Microsoft.SqlServer.Management.SqlManagerUI.AttachDatabaseData.PrimaryFile.PopulateAssociatedFiles(String primaryFilePath)
       at Microsoft.SqlServer.Management.SqlManagerUI.AttachDatabaseData.PrimaryFile.PopulatePrimaryFileData(String primaryFilePath)
       at Microsoft.SqlServer.Management.SqlManagerUI.AttachDatabaseData.PrimaryFile..ctor(SqlManagementUserControl parent, CDataContainer dc, String fullPath, String databaseOwner, ServerConnection connectionInfo)
       at Microsoft.SqlServer.Management.SqlManagerUI.AttachDatabase.IsSelectedFileValid(BrowseFolder dlg
      
      
      
     The restriction of not allowing Kernel object names during directory lookup has been added in the .Net layer and when the control from management studio gets passed on to traverse the location of the LDF file from DBCC CHECKPRIMARYFILE output we are hitting this restriction.


    The DPM application internally uses AUTORECOVERY option during backup. This instructs SQL Writer to take a snapshot of the database and then re-attach them back to SQL Server from the backup location so that it can reduce the recovery timeframe in case if this backup has to be restored. Since VSS internally maps a Shadow copy of the path the relative path gets converted to \\?\GlobalRoot

    Example: Given the path:  E:\Vol_P\UserDB\MSSQL\Data\DBNAME.mdf changes to \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy####\MSSQL\Data\DBNAME.mdf

    Since we are attaching the database from this shadow copy path this path gets overwritten in to the header of the MDF File and when management studio internally fires DBCC CHECKPRIMARYFILE to get the actual path of the files we end up in this situation.

    As a workaround measure you can keep the MDF and LDF file in a single location during attach process so that management studio doesn’t need to traverse the path. Apart from this you can always use a TSQL Statement “CREATE Database FOR Attach” to attach the databases.
    >snip<

     


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    • Marked as answer by tpullins Monday, October 14, 2013 7:44 AM
    Wednesday, October 9, 2013 3:43 PM
    Moderator
  • That appears to work! I did notice that when attaching SQLMS picks up the database name as something like RollbackSnapshotTempDB{A6614A3D-E686-43ED-A310-B3742F142AD3}. But I suppose it shouldn't make a difference if I enter the correct name in "Attach As".

    Was the SharePoint protection component changed for DPM 2012 and SP2013? I didn't have this issue when protecting a SP2010 farm with DPM 2010.

    Wednesday, October 9, 2013 5:12 PM
  • Hi,

    Glad that workaround resolved the issue.  Yes, DPM 2012 uses AUTORECOVERY option during backups.  DPM 2010 did not use that flag.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, October 9, 2013 5:35 PM
    Moderator