469,366 Members | 2,503 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,366 developers. It's quick & easy.

Run-Time Check Failure #0 ....

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
Nov 17 '05 #1
11 7710
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.

Nov 17 '05 #2
"zhong" <zh*************@tek.com> wrote in message
news:04****************************@phx.gbl...
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.
Nov 17 '05 #3
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.
--------------------

Nov 17 '05 #4
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 Iwill 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, pleasefeel free to let me know.

Based on my experience, if your program don't have an explicit functionpointer that points to a different calling convention function, maybe itwould be the situation which Tom figured in the above post.
However, without further information about your program, we have no waysto find out the problem exactly. Would please help me collect moreinformation about your program for further troubleshooting, such as what'stype of your project, do the program call some DLL's function, and what'sthe 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.--------------------

.

Nov 17 '05 #5
"Zhong" <an*******@discussions.microsoft.com> wrote in message
news:02****************************@phx.gbl...
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
Nov 17 '05 #6
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-----
"Zhong" <an*******@discussions.microsoft.com> wrote in messagenews:02****************************@phx.gbl...
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 withWaitForSingleObject() it is in my view an extraordinarily remote one becausethe function is so central to asynchronous processing.

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

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

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

Regards,
Will
.

Nov 17 '05 #7
>>>The error does not happen all the time, but it does happen frequently.
I saw this error when I run the following function repeatedly in a loop
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

--------------------Content-Class: urn:content-classes:message
From: "zhong" <zh*************@tek.com>
Sender: "zhong" <zh*************@tek.com>
References: <04****************************@phx.gbl> <HF*************@cpmsftngxa08.phx.gbl>
<02****************************@phx.gbl>
<uT**************@tk2msftngp13.phx.gbl>Subject: Re: Run-Time Check Failure #0 ....
Date: Mon, 19 Jan 2004 13:18:34 -0800
Lines: 141
Message-ID: <03****************************@phx.gbl>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Newsreader: Microsoft CDO for Windows 2000
Thread-Index: AcPe0cwOWojXDZmQQfysApNVuIKQyw==
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Newsgroups: microsoft.public.dotnet.languages.vc
Path: cpmsftngxa07.phx.gbl
Xref: cpmsftngxa07.phx.gbl microsoft.public.dotnet.languages.vc:32120
NNTP-Posting-Host: tk2msftngxa09.phx.gbl 10.40.1.161
X-Tomcat-NG: microsoft.public.dotnet.languages.vc

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-----
"Zhong" <an*******@discussions.microsoft.com> wrote in
message
news:02****************************@phx.gbl. ..
> 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
.


Nov 17 '05 #8
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.

Nov 17 '05 #9
Thanks, Prab. You are right. After I make the change, it works now.

zhong
Nov 17 '05 #10

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
-----------------------------------------------------------------------
Posted via http://www.mcse.m
-----------------------------------------------------------------------
View this thread: http://www.mcse.ms/message284817.htm

Nov 17 '05 #11
>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
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq
Nov 17 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

13 posts views Thread by Bob Day | last post: by
3 posts views Thread by emman_54 | last post: by
19 posts views Thread by Bryan | last post: by
9 posts views Thread by Brett Wesoloski | last post: by
8 posts views Thread by David Thielen | last post: by
3 posts views Thread by traceable1 | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by suresh191 | last post: by
1 post views Thread by Marylou17 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.