3624 Errors

I have a 2-node cluster (32-bit) at 8.00.818 that has approximately 100
databases of varying sizes that are used to feed some tax websites. Recently
we did a repair on one of the databases with a DBCC CHECKDB with
ALLOW_DATA_LOSS to repair some issues with one database. That went well.
Last weekend we started getting 3624 errors.
2007-02-05 12:04:28.99 spid88 Error: 3624, Severity: 20, State: 1.
2007-02-05 12:04:27.98 spid88 SQL Server Assertion: File:
<R:\sql\ntdbms\storeng\drs\include\record.inl>, lin
2007-02-05 12:04:27.98 spid88 Stack Signature for the dump is 0xD13C4E9C
2007-02-05 12:04:21.49 spid88 Using 'dbghelp.dll' version '4.0.5'...
2007-02-05 12:04:16.90 spid122 Error: 3624, Severity: 20, State: 1.
2007-02-05 12:04:16.15 spid122 SQL Server Assertion: File:
<R:\sql\ntdbms\storeng\drs\include\record.inl>, lin
2007-02-05 12:04:16.15 spid122 Stack Signature for the dump is 0xACA26EF6
2007-02-05 12:04:07.01 spid122 Using 'dbghelp.dll' version '4.0.5'...
Looking at the dumps it takes, seems like most of these get generated when a
backupjobs runs that backs up to off-site EMC devices. Any ideas on how I
can get this fixed or what to look at?
When you get these dumps like this it is best to open a support incident
with Microsoft and have them debug it. Do you get these dumps when you do a
native backup?
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Cathy Soloway" <CathySoloway@.discussions.microsoft.com> wrote in message
news:DBF05514-9A16-4C95-84DF-E850D9EAF878@.microsoft.com...
>I have a 2-node cluster (32-bit) at 8.00.818 that has approximately 100
> databases of varying sizes that are used to feed some tax websites.
> Recently
> we did a repair on one of the databases with a DBCC CHECKDB with
> ALLOW_DATA_LOSS to repair some issues with one database. That went well.
> Last weekend we started getting 3624 errors.
> 2007-02-05 12:04:28.99 spid88 Error: 3624, Severity: 20, State: 1.
> 2007-02-05 12:04:27.98 spid88 SQL Server Assertion: File:
> <R:\sql\ntdbms\storeng\drs\include\record.inl>, lin
> 2007-02-05 12:04:27.98 spid88 Stack Signature for the dump is 0xD13C4E9C
> 2007-02-05 12:04:21.49 spid88 Using 'dbghelp.dll' version '4.0.5'...
> 2007-02-05 12:04:16.90 spid122 Error: 3624, Severity: 20, State: 1.
> 2007-02-05 12:04:16.15 spid122 SQL Server Assertion: File:
> <R:\sql\ntdbms\storeng\drs\include\record.inl>, lin
> 2007-02-05 12:04:16.15 spid122 Stack Signature for the dump is 0xACA26EF6
> 2007-02-05 12:04:07.01 spid122 Using 'dbghelp.dll' version '4.0.5'...
> Looking at the dumps it takes, seems like most of these get generated when
> a
> backupjobs runs that backs up to off-site EMC devices. Any ideas on how I
> can get this fixed or what to look at?
|||The thing that is confusion is this R: drive location is actually a
CD-ROM--that's why I suspect hardware problems the most. The backups work
intermittently from jobs and or native launch.
"Cathy Soloway" wrote:

> I have a 2-node cluster (32-bit) at 8.00.818 that has approximately 100
> databases of varying sizes that are used to feed some tax websites. Recently
> we did a repair on one of the databases with a DBCC CHECKDB with
> ALLOW_DATA_LOSS to repair some issues with one database. That went well.
> Last weekend we started getting 3624 errors.
> 2007-02-05 12:04:28.99 spid88 Error: 3624, Severity: 20, State: 1.
> 2007-02-05 12:04:27.98 spid88 SQL Server Assertion: File:
> <R:\sql\ntdbms\storeng\drs\include\record.inl>, lin
> 2007-02-05 12:04:27.98 spid88 Stack Signature for the dump is 0xD13C4E9C
> 2007-02-05 12:04:21.49 spid88 Using 'dbghelp.dll' version '4.0.5'...
> 2007-02-05 12:04:16.90 spid122 Error: 3624, Severity: 20, State: 1.
> 2007-02-05 12:04:16.15 spid122 SQL Server Assertion: File:
> <R:\sql\ntdbms\storeng\drs\include\record.inl>, lin
> 2007-02-05 12:04:16.15 spid122 Stack Signature for the dump is 0xACA26EF6
> 2007-02-05 12:04:07.01 spid122 Using 'dbghelp.dll' version '4.0.5'...
> Looking at the dumps it takes, seems like most of these get generated when a
> backupjobs runs that backs up to off-site EMC devices. Any ideas on how I
> can get this fixed or what to look at?
|||First of all, you could apply SP 4 (2039) and the publicly available
Cumulative Hotfix Rollup (2187). There have been quite a few fixes in the
last...4 years (yes, SP3 + MS03-031, build 818 was released in 1Q03 and
3Q03) that you might want to apply.
The R: drive you are referring to may be an old link in the registry keys.
Look at HKLM\SOFTWARE\Microsoft SQL Server\<instance name> for named
instances or HKLM\SOFTWARE\Microsoft\MSSQL for default instances.
Sincerely,
Anthony Thomas

"Cathy Soloway" <CathySoloway@.discussions.microsoft.com> wrote in message
news:A9A7A5B3-E9CE-4F74-A161-44868CF3FE1B@.microsoft.com...
> The thing that is confusion is this R: drive location is actually a
> CD-ROM--that's why I suspect hardware problems the most. The backups
work[vbcol=seagreen]
> intermittently from jobs and or native launch.
> "Cathy Soloway" wrote:
Recently[vbcol=seagreen]
well.[vbcol=seagreen]
0xD13C4E9C[vbcol=seagreen]
0xACA26EF6[vbcol=seagreen]
when a[vbcol=seagreen]
I[vbcol=seagreen]
|||I did a full registry search for that path on both nodes and it's not there.
That's why I thought something was amiss hardware wise. I'm continuing to
monitor and have to research any implications of applying SP4 plus the
following rollup, but that's not a quick fix. The system currently is at
8.00.818.
"Cathy Soloway" wrote:

> I have a 2-node cluster (32-bit) at 8.00.818 that has approximately 100
> databases of varying sizes that are used to feed some tax websites. Recently
> we did a repair on one of the databases with a DBCC CHECKDB with
> ALLOW_DATA_LOSS to repair some issues with one database. That went well.
> Last weekend we started getting 3624 errors.
> 2007-02-05 12:04:28.99 spid88 Error: 3624, Severity: 20, State: 1.
> 2007-02-05 12:04:27.98 spid88 SQL Server Assertion: File:
> <R:\sql\ntdbms\storeng\drs\include\record.inl>, lin
> 2007-02-05 12:04:27.98 spid88 Stack Signature for the dump is 0xD13C4E9C
> 2007-02-05 12:04:21.49 spid88 Using 'dbghelp.dll' version '4.0.5'...
> 2007-02-05 12:04:16.90 spid122 Error: 3624, Severity: 20, State: 1.
> 2007-02-05 12:04:16.15 spid122 SQL Server Assertion: File:
> <R:\sql\ntdbms\storeng\drs\include\record.inl>, lin
> 2007-02-05 12:04:16.15 spid122 Stack Signature for the dump is 0xACA26EF6
> 2007-02-05 12:04:07.01 spid122 Using 'dbghelp.dll' version '4.0.5'...
> Looking at the dumps it takes, seems like most of these get generated when a
> backupjobs runs that backs up to off-site EMC devices. Any ideas on how I
> can get this fixed or what to look at?
||| The R drive was probably a network share on the developer/build machine
at Microsoft where the code was compiled.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Cathy Soloway" <CathySoloway@.discussions.microsoft.com> wrote in message
news:A9A7A5B3-E9CE-4F74-A161-44868CF3FE1B@.microsoft.com...[vbcol=seagreen]
> The thing that is confusion is this R: drive location is actually a
> CD-ROM--that's why I suspect hardware problems the most. The backups
> work
> intermittently from jobs and or native launch.
> "Cathy Soloway" wrote: