I have recently started getting a CRC error when running some code. It only seems to occur the first time I load the page; if I refresh, it takes ages, but eventually laods OK. But something simple like loading a user control with take c80s.
The code/platform in use is one that is used for other reports - this is essentially a new report on an existing platform a nd I've never seen this error before. Judging by the lack of useful google results, I'm guessing not many other people have either
but it's worth a shot in case someone cna help.
I've enabled trace on my web page and it seems to fall over on loading a web control, e.g.
Dim FP As New Object
FP = LoadControl("controls/FrontPage.ascx")
The FrontPage.ascx control is actually used in other reports successfully and in fact an almost identical report works (only difference is it's source language (En vs US). However I've examined the DB records for both EN and US as well as the code, etc
and can't see how or where this could throw this error.
I've actually tried recreating the affected control and the report will then work for that user control but fall over on another one. Having done it on all of the user controls in my system, I thought I'd cracked it, but have now run a report on a new dataset
and get the error all over again!!!
Anyone seen this or have any ideas of what to look for...?
Thanks - I'd seen those links, but like you say there's no real way to test the CRC.
However, for anyone else who may come across this I have got it working on a new web server (just because one was available!) and here is my thinking about the issue:
- the CRC is a system-level (i.e. sub-code) check that does something like a check sum to confirm that the data returned is from the originating request. When this is different a CRC error is shown.
- this error is most commonly found when you are trying to acces some data on a bad sector on a hard drive (from what I understand)
- I was able to run the web server locally against the live DB, implying that the issue lay with the actual files in the web site
- the code fell over when trying to create a user control; therefore the issue must be that the user control .ascx file (or the BIN I guess?) lay on a bad sector on the live server
- however, running chkdsk didn't pick up any bad sectors
- when running the site on a new server, the issue wasn't found further reinforcing the thought that the issue is something to do with the web files somehow.
- if you don't have a new server you can use, I reckon creating the user control again under a different name (or renaming the 'broken' one) should resolve it as it would be stored on a new sector (assumiong that new sector isn't corrupt as well).
So... all is happy in my world with the site now, although the issue still exists until such time as we cna port the site to the new server permanently.
gingawarrior
Member
64 Points
71 Posts
Data error (cyclic redundancy check) in ASP.NET 2.0
Jul 04, 2011 03:14 PM|LINK
Oddness.
I have recently started getting a CRC error when running some code. It only seems to occur the first time I load the page; if I refresh, it takes ages, but eventually laods OK. But something simple like loading a user control with take c80s.
The code/platform in use is one that is used for other reports - this is essentially a new report on an existing platform a nd I've never seen this error before. Judging by the lack of useful google results, I'm guessing not many other people have either but it's worth a shot in case someone cna help.
I've enabled trace on my web page and it seems to fall over on loading a web control, e.g.
Dim FP As New Object
FP = LoadControl("controls/FrontPage.ascx")
The FrontPage.ascx control is actually used in other reports successfully and in fact an almost identical report works (only difference is it's source language (En vs US). However I've examined the DB records for both EN and US as well as the code, etc and can't see how or where this could throw this error.
I've actually tried recreating the affected control and the report will then work for that user control but fall over on another one. Having done it on all of the user controls in my system, I thought I'd cracked it, but have now run a report on a new dataset and get the error all over again!!!
Anyone seen this or have any ideas of what to look for...?
Zizhuoye Che...
All-Star
21915 Points
1915 Posts
Re: Data error (cyclic redundancy check) in ASP.NET 2.0
Jul 07, 2011 07:08 AM|LINK
Hi,
Not very sure how do you check the CRC. But maybe you can have a look at these links:
http://www.codeproject.com/KB/recipes/crc32_dotnet.aspx
http://www.aspfree.com/c/a/C-Sharp/Cyclic-Redundancy-Check/
Hope this can help.
If you have any feedback about my replies, please contact msdnmg@microsoft.com
Microsoft One Code Framework
gingawarrior
Member
64 Points
71 Posts
Re: Data error (cyclic redundancy check) in ASP.NET 2.0
Jul 07, 2011 08:56 AM|LINK
Thanks - I'd seen those links, but like you say there's no real way to test the CRC.
However, for anyone else who may come across this I have got it working on a new web server (just because one was available!) and here is my thinking about the issue:
- the CRC is a system-level (i.e. sub-code) check that does something like a check sum to confirm that the data returned is from the originating request. When this is different a CRC error is shown.
- this error is most commonly found when you are trying to acces some data on a bad sector on a hard drive (from what I understand)
- I was able to run the web server locally against the live DB, implying that the issue lay with the actual files in the web site
- the code fell over when trying to create a user control; therefore the issue must be that the user control .ascx file (or the BIN I guess?) lay on a bad sector on the live server
- however, running chkdsk didn't pick up any bad sectors
- when running the site on a new server, the issue wasn't found further reinforcing the thought that the issue is something to do with the web files somehow.
- if you don't have a new server you can use, I reckon creating the user control again under a different name (or renaming the 'broken' one) should resolve it as it would be stored on a new sector (assumiong that new sector isn't corrupt as well).
So... all is happy in my world with the site now, although the issue still exists until such time as we cna port the site to the new server permanently.