1

We have a mid-size solution holding projects targeting Net 7, NetStandard 2.1 and Blazor. Some time ago it raised a System.AccessViolationException exception, by that time, we search for changes in our code and were able to workaround it removing references to the Sql Server Diagram stored procedures. Recently it showed up in different development environments. We are able to workaround it by cloning the repository in a new folder. We thought if the issue was in the folder, by removing the folder in cloning it again on a new folder with the same name, it would just work. For our surprise, the error remains. We have tried removing temp folders, .nuget folder, reinstalling packages but still we cannot narrow to something that we can reproduce. The exception is: "System.AccessViolationException   HResult=0x80004003   Message=Attempted to read or write protected memory. This is often an indication that other memory is corrupt." And it happens in different places, but always when making a call or referencing the assembly that "talks" with the database. We are using facil and Microsoft.Data.SqlClient (5.1.1) to communicate with the DB, but what is quite strange, is that just by moving the project to a new folder, it start working. So, here is my question: Is there any other place/folder, where dotnet or Visual Studio (17.5.4) keeps a reference to the solution or projects? Any help will be welcomed, this issues is driving us crazy.

We have tried many things: cleaning, refreshing packages, reinstalling Visual Studio. What we expect is not seeing that exception because it happens based on the folder where the project is located.

Mauricio
  • 43
  • 5
  • This sounds like an intermittent problem in unmanaged code. I doubt that copying everything to a new folder actually fixes anything. It just appears that way because the corruption takes a while to occur after a clean build. I think your best bet for solving the problem (or at least getting help here) is to methodically reduce code and dependencies until you have a small example app that reproduces the behavior you're seeing. – Brian Berns Apr 20 '23 at 03:51
  • Hello Brian, we have tried doing what you suggest. In some development computers it just works (like in mine), once deployed, it just works. Keep in mind that, just creating a brand new folder with the very same name and doing a clean clone to that folder, it keeps failing... that led me to think in a cache or stored info in some place I cannot find... – Mauricio Apr 20 '23 at 04:58
  • I have found that by splitting the assembly it just works. It looks like something runs out of capacity so, dealing with smaller assemblies and/or files it is able to manage it properly. This is just a workaround, I hope it is useful. – Mauricio May 12 '23 at 13:52

0 Answers0