c++ strange c0000005 error
I think the problem lies within the
LPSERVICE_STATUS xyz = (LPSERVICE_STATUS)malloc(sizeof(LPSERVICE_STATUS));
ControlService(schs,SERVICE_CONTROL_STOP,xyz);
part. The last argument xyz to ControlService is used by that API to return status information about the service. You are actually passing a pointer to a pointer sized memory region here, which is too small to hold all the values, which ControlService would like to fill in. IMHO you get bitten at run-time, because executing the ControlService call will override random memory directly after the space for the pointer allocated by malloc.
Try
SERVICE_STATUS xyz;
memset(&xyz, 0, sizeof(xyz));
ControlService(schs, SERVICE_CONTROL_STOP, &xyz);
instead. There is no need to allocate the structure dynamically here. According to the documentation, the ControlService will only use it to return status information; it won't be stored somewhere within Windows internal data structures.
More about the content of the structure can be in the MS documentation. No idea, why it might work during debugging. Maybe, the malloc linked against for debugging behaves slightly differently in comparison to the production version malloc?
New to C, C0000005 and crash error due to long calculation?
The code has a few issues that stand out, you are accessing k
out of bounds in a few places, for example:
if (j==1){k[i][1]=h*System(i,x[0]+k[0][0]/2.0,x[1]+k[1][0]/2.0,x[2]+k[2][0]/2.0,
^^^
x[3]+k[3][0]/2.0);}
^^^
k
is declared as k[3][4]
and so 3
is one outside the bounds of k
since the indicies start at 0
. As Jonathan points out sicne your loops seems to indicate that you really meant to declare k
as k[4][4]
which would fix this problems.
In System
if i
is not 0 to 3
then you will fall out of function without a return which is undefined behavior for a value returning function. As Jonathan already mentioned System
is probably not a good choice as a name since it is very close to the standard system()
function.
How to debug access violation 0xC0000005 in CorExitProcess on exit?
I tried debugging this using data breakpoints, but that didn't help a lot. I could see that at some point the data being accessed was overwritten, but that didn't happen in a call stack containing any of my own code.
So I resorted in a simpler method and started removing parts of the program until the error disappeared. In a large application it may be hard to remove some parts without breaking others, but I was able to narrow down the source of the issue.
Basically, the problem stopped occurring after removing a certain call to FreeLibrary
. After further investigation it turned out that this call happens during DllMain
, which is not allowed:
The entry-point function should perform only simple initialization or termination tasks. It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code. Similarly, the entry-point function must not call the FreeLibrary function (or a function that calls FreeLibrary) during process termination, because this can result in a DLL being used after the system has executed its termination code.
In another SO question, one user apparently noticed a change since Windows 8 in this regard, which would explain why the error only happens on this version of Windows.
We'll now change our application so that FreeLibrary
is called at a different point of time.
Related Topics
Glut Deprecation in MAC Osx 10.9, Ide: Qt Creator
Why "Not All Control Paths Return a Value" Is Warning and Not an Error
Auto' as a Template Argument Placeholder for a Function Parameter
Lambdas and Capture by Reference Local Variables:Accessing After the Scope
Ramifications of C++20 Requiring Two's Complement
Remote Debugging C++ Applications with Eclipse Cdt/Rse/Rdt
How to Convert from Lpctstr to Std::String
Static Variable in the Class Declaration or Definition
C++ Static Const Access Through a Null Pointer
How to Enforce C++ Compiler to Use Specific Crt Version
Efficient Multiply/Divide of Two 128-Bit Integers on X86 (No 64-Bit)