A system assertion check failed when using filestreams (longrec.inl:1318) - by Bart Vandromme

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 761048 Comments
Status Closed Workarounds
Type Bug Repros 1
Opened 9/4/2012 12:55:52 AM
Access Restriction Public


A system assertion check failure comes up when transferring data from a "varbinary(MAX)" field to a "varbinary(MAX) FILESTREAM" field.  This does only happen with sql server 2012.  In sql server 2008 this is handled correctly.

* BEGIN STACK DUMP:                                                                                              
*   09/03/12 10:10:50 spid 53                                                                                    
* Location:	 e:\sql11_main_t\sql\ntdbms\storeng\include\longrec.inl:1318                                         
* Expression:	 outBufLen >= offsetof (InRowContent, m_varBlobCol) + inBufLen                                     
* SPID:		 53                                                                                                     
* Process ID:	 8996                                                                                              
Sign in to post a comment.
Posted by Microsoft on 4/3/2013 at 10:55 AM
I am happy to report that we have found the root cause for this bug, and have fixed it.
We appreciate your feedback which enables us to find and fix issues like this.
The fix will ship in the next version of SQL Server, as well as in future Cumulitive Updates for prior versions.
Posted by Microsoft on 3/8/2013 at 8:06 AM
Thank you very much for the information. The problem has something to do with the dropped columns you have on the table. We are still investigating to find the root cause. At the same time, you can work around this by first doing a rebuild on the table. That will clean up the dropped columns and then adding the constraint will work with no error. Thanks.
Posted by Bart Vandromme on 2/22/2013 at 4:28 AM
It is indeed step 6 that fails. To simplify the analyses, I sended you the backup off the database, so you only need to do the following steps to reproduce the problem:

1. Restore the sended database
2. execute the following query which should fail: ALTER TABLE [ResourceTypeRevisionDocumentation] ADD CONSTRAINT [PK_ResourceTypeRevisionDocumentation] PRIMARY KEY([Kind],[ID],[Rev],[SubRev],[DocCategory],[DocIndex])

Thanks for looking into it.

Posted by Microsoft on 2/20/2013 at 10:41 AM
I see that you attached the backup files...

Can you send the actual queries, and it's step 6 that cause the failure?

Also the alter statement failure - it's not related to the scenario but generate the same error?

Posted by Bart Vandromme on 1/2/2013 at 6:38 AM
Sorry for the late reply, but the problem is still there, so I can provide you with some additional information.

I have a backup of a database (SQL Server 2012 Express SP1). When I execute the following command, I get the same error:
ALTER TABLE [ResourceTypeRevisionDocumentation] ADD CONSTRAINT [PK_ResourceTypeRevisionDocumentation] PRIMARY KEY([Kind],[ID],[Rev],[SubRev],[DocCategory],[DocIndex])

Where do I need to send the backup file ?

Bart Vandromme
Posted by Microsoft on 9/10/2012 at 8:27 AM
Thanks for reporting the assertion error in FILESTREAM. Would it be possible to identify/supply the actual data row at which the error occurred? That may help debugging this issue further.

SQL Server team