Run-Time Check Failure #0 ....

  • Thread starter Thread starter zhong
  • Start date Start date
Z

zhong

Error Message:

Run-Time Check Failure #0 - The value of ESP was not
properly saved across a function call. This is usually a
result of calling a function declared with one calling
convention with a function pointer declared with a
different calling convention.

There are several answers to this error, but my situation
is different. The place I get this error is at
WaitForSingleObject(). This is the builtin function, how
can I get around of this?

Thanks,

zhong
 
Hello Zhong,

Thanks for posting in the group.

Currently I am looking for somebody who could help you on it. We will reply
here with more information as soon as possible. If you have any more
concerns on it, please feel free to post here.

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
zhong said:
Error Message:

Run-Time Check Failure #0 - The value of ESP was not
properly saved across a function call. This is usually a
result of calling a function declared with one calling
convention with a function pointer declared with a
different calling convention.

There are several answers to this error, but my situation
is different. The place I get this error is at
WaitForSingleObject(). This is the builtin function, how
can I get around of this?
zhong

Hard to tell. But are you perhaps calling a function in a dll that uses
different calling conventions than MS conventions?

Tom.
 
Hi zhongsheng,

Thanks for using Microsoft MSDN Managed Newsgroup. My name is Gary, and I
will be assisting you on this issue.

First of all, I would like to confirm my understanding of your issue.

From your description, I understand that you get a "Run-Time Check Failure
#0" when your program run steps into WaitForSingleObject() API call.
Have I fully understood you? If there is anything I misunderstood, please
feel free to let me know.

Based on my experience, if your program don't have an explicit function
pointer that points to a different calling convention function, maybe it
would be the situation which Tom figured in the above post.

However, without further information about your program, we have no ways
to find out the problem exactly. Would please help me collect more
information about your program for further troubleshooting, such as what's
type of your project, do the program call some DLL's function, and what's
the context of the error code line....


Thanks!

Best regards,

Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
 
Hi, Gary:

I did post the reply last week, but it seems there is
problem to display my message. Any way, here is where I
have the problem:

I have written the driver test application. I need use
the overlapped I/O to make asynchronous driver call.
After I called DeviceIoControl(), the stack is still
valid. However, when I step into WaitForSingleObject()
function call in the disassembly code, the stack
disappears. The default calling convention is __cdecl()
for the application, but I believe WaitForSingleObject()
is using __stdcall() calling convention. The problem is
WaitForSingleObject() is the builtin function, which is
out of my control. What I would like to know is how I can
get around.

I will try to post this message to the newsgroup.

Thanks for your help,


zhong
-----Original Message-----
Hi zhongsheng,

Thanks for using Microsoft MSDN Managed Newsgroup. My name is Gary, and I
will be assisting you on this issue.

First of all, I would like to confirm my understanding of your issue.

From your description, I understand that you get a "Run- Time Check Failure
#0" when your program run steps into WaitForSingleObject () API call.
Have I fully understood you? If there is anything I misunderstood, please
feel free to let me know.

Based on my experience, if your program don't have an explicit function
pointer that points to a different calling convention function, maybe it
would be the situation which Tom figured in the above post.

However, without further information about your program, we have no ways
to find out the problem exactly. Would please help me collect more
information about your program for further
troubleshooting, such as what's
 
Zhong said:
I have written the driver test application. I need use
the overlapped I/O to make asynchronous driver call.
After I called DeviceIoControl(), the stack is still
valid. However, when I step into WaitForSingleObject()
function call in the disassembly code, the stack
disappears. The default calling convention is __cdecl()
for the application, but I believe WaitForSingleObject()
is using __stdcall() calling convention. The problem is
WaitForSingleObject() is the builtin function, which is
out of my control. What I would like to know is how I can
get around.

Pardon me for jumping into this conversation.

First, while it is always a possibility that there is a problem with
WaitForSingleObject() it is in my view an extraordinarily remote one because
the function is so central to asynchronous processing.

My guess is that there is stack corruption which just gets attributed to
WFSO().

One thing to check is that all of the data structures that are involved in
an async operation live until the operation completes. Sometimes developers
make mistakes by using an automatic (i.e. a stack-based) OVERLAPPED
structure in a function which returns before the I/O completes while the
wait is performed by the caller of that function. By the time the I/O
completes, the address passed to the read or write now points somewhere
else.

If that "somewhere else" is a stack frame, you will see the error that you
report.

Regards,
Will
 
Thanks, Bill:

I agree with you, but it seems it is not the case in my
function. Here is my code snipet. Please let me know if
you find anything weird. The error does not happy all the
time, but it does happen frequently. I saw this error
when I run the following function repeatedly in a loop
especially on Windows 2000.

Thanks,

zhong


// Omit the error check of course.
int DD_StartDma( ... )
{

DWORD StatusCode;
IOCTLDATA IoBuffer;
OVERLAPPED OverLapped, *pOverLapped;
HANDLE hEvent;
RETURN_CODE code = ApiSuccess;

hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
OverLapped.hEvent = hEvent;
OverLapped.Offset = 0;
OverLapped.OffsetHigh = 0;

memset(&(IoBuffer.u.DmaData.u.TxParams), 0, sizeof
(DMA_TRANSFER_ELEMENT));

// Initialize IoBuffer for transaction
IoBuffer.u.DmaData.u.TxParams.LocalToPciDma =
bLocal2Pci;
IoBuffer.u.DmaData.u.TxParams.TransferCount =
size;
IoBuffer.u.DmaData.u.TxParams.u.UserVa =
(UINT32)pUserVa; // Virtual address of buffer
IoBuffer.u.DmaData.u.TxParams.Offset =
nOffset;
IoBuffer.u.DmaData.u.TxParams.LocalAddr =
LocalAddress; // Local bus address
IoBuffer.u.DmaData.channel
= (DMA_CHANNEL)uChan;
IoBuffer.ReturnCode
= ApiSuccess;

// Macro for DeviceIoControl() call
IoMessage(
m_hDevice,
MDL_DMA_TRANSFER,
&(IoBuffer),
sizeof(IOCTLDATA),
&OverLapped
);

StatusCode = WaitForSingleObject(hEvent,
MAX_DMA_TIMEOUT );

switch (StatusCode)
{
case WAIT_OBJECT_0:
TRACE("Exit ... DD_StartDma succeeds ...\n");
code = ApiSuccess;
break;

case WAIT_TIMEOUT:
TRACE("Exit ... DD_StartDma timeout ...\n");
code = ApiPciTimeout;
break;

case WAIT_FAILED:
TRACE("Exit ... DD_StartDma failed ...\n");
code = ApiFailed;
break;

default:
TRACE("Exit ... DD_StartDma failed ...\n");
code = ApiFailed;
break;
}

CloseHandle(hEvent);
}

return code;
-----Original Message-----


Pardon me for jumping into this conversation.

First, while it is always a possibility that there is a problem with
WaitForSingleObject() it is in my view an
extraordinarily remote one because
 
The error does not happen all the time, but it does happen frequently.
In the code snippet below (i.e. in DD_StartDma function), you are passing a
pointer to OVERLAPPED structure that is declared on the stack. If
DD_StartDma function returns before your asynchronous I/O completes, (e.g.
for the case where a WaitForSingleObject() call returned after your timeout
specified MAX_DMA_TIMEOUT), the pointer to OVERLAPPED structure you passed
for asynchronous I/O request you just issued (but not completed), is bogus
thereafter. When the asynchronous I/O completes later, it will corrupt the
stack when the OVERLAPPED structure is updated as it is pointer on the
stack of the thread that issued the /IO.

The lpOverlapped parameter *must* be valid for the duration of the
overlapped operation. i.e. until overlapped I/O completes. Allocate memory
for the overlapped structure on the heap.

If multiple I/O operations are simultaneously outstanding, each must
reference a separate OVERLAPPED structure, hEvent etc so that you have one
to one mapping for the corresponding asynchronous I/O.

Thanks,
Prab

--------------------
 
Hello Zhong,

How are things going? I would appreciate it if you could post here to let
us know the status of the issue. If you have any questions or concerns,
please don't hesitate to let us know. We look forward to hearing from you,
and we am happy to be of assistance.

Thanks for participating the community.

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Well, im having the same problem when calling ID3DXSPRITE::Draw() thi
may be the wrong place to talk about a direct x function... but..
since i dont really know much assembly... i dont really know what
going on, im not calling a function pointer (i dont think....)

heres the code

bool SPRITE::Render()
{
if (FAILED(SPRITE::Sprite->Draw(SPRITE::pTex, NULL, NULL, NULL, NULL
&(SPRITE::Position), 0xFFFFFFFF)))
return FALSE;
return TRUE;
}

where SPRITE is my encapsulation class, Sprite is an LPD3DXSPRIT
(ID3DXSPRITE *) and position is a D3DXVECTOR2 (2 floats), the erro
seemed to only crop up after i defined the same function for a derive
class (its virtual)

yeha if anyone knows what im rambling about and how to remedy it.
thatd be great... thanx al

Adema
 
Well, im having the same problem when calling ID3DXSPRITE::Draw() this
may be the wrong place to talk about a direct x function... but...
since i dont really know much assembly... i dont really know whats
going on, im not calling a function pointer (i dont think....)
...
...the error
seemed to only crop up after i defined the same function for a derived
class (its virtual)

A virtual function is called via a pointer, so, its a similar
situation. However, I've no experience with ID3DXSPRITE::Draw and I
can't imagine how it could easily be misused providing you've used the
definitions in the standard header files.

Since the problem only occurred when you added the derived class, I'd
certainly suspect something that's not right in that area. Sorry I
can't tell you anything definite.

Dave
 
Back
Top