473,327 Members | 2,007 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,327 software developers and data experts.

Strange Error

Hi all,

I keep getting a strange error and can't pin it down. The message is:

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.

However I'm not purposely requesting that the Runtime terminate in an
"unusual way." The line that is causing me headaches is:

wcscpy(data, MyCode.c_str());

Where data and MyCode are defined as:

wchar_t data[256];
std::wstring AuthorCode;

The strange thing is that the program appears to be running fine in Visual
Studio, but generates the error message whenever I try to run it from the
command line. Putting a try...catch block around the line in question
doesn't help - it doesn't catch the exception. I have no idea what's
causing this...

Any ideas are appreciated!

Thanks!
Sep 12 '06 #1
11 2438
Just a guess for a starting point...

wcscpy is a wide character function, and its second parameter expects a
wide character string to copy from. In your example, you are using
c_str which is not a wide character function - it returns a string of 8
bit chars. wcscpy will attempt to combine every two bytes as a single
"character" in your input string. If you have an odd number of chars
in this string, wcscpy will attempt to access memory outside of the
string when it hits the last character, which may cause the crash?

Andy

B.T.W.

I'm having trouble accessing an unmanaged long from a managed class in
VC++.NET

When I do, the contents of the variable seem to be mangled. If I
access the same variable byte-by-byte, I get the correct value.
Regardless what I set the variable to, the value that is returned for a
long is always the same value. What's going on...can anyone help me?

A short version of the code follows:

//HEADER
namespace MyProgram
{

#pragma unmanaged
__nogc class unmanagedClass
{
public:unmanagedClass(); //CONSTRUCTOR

public: union{
struct {
long unmanagedLong; //UNMANAGED VARIABLE
} myData;
struct {
char bytes[4];
} b_myData;
} myUnion;
};
#pragma managed
public __gc class managedClass
{
public:managedClass(); //CONSTRUCTOR
private: unmanagedClass __nogc *ptrUnmanagedClass; //PTR TO UNMANAGED
CLASS
public:System::String* Get_unmanagedLong(); //METHOD TO GET
UNMANAGED VARIAHBLE
};
}

//CPP LISTING

//CONSTRUCTORS
MyProgram::unmanagedClass::unmanagedClass(){
unmanagedLong=1536; //HEX #0600
}
MyProgram::managedClass::managedClass(){
ptrUnmanagedClass=new unmanagedClass();
}
System::String* MyProgram::managedClass::Get_unmanagedLong(){
System::String *result;

//NEXT RETURNS CORRECT VALUE OF #0600
result=System::String::Concat(

System::String::Format("{0:x}",__box(ptrUnmanagedC lass->myUnion.b_myData.bytes[0])),

System::String::Format("{0:x}",__box(ptrUnmanagedC lass->myUnion.b_myData.bytes[1])),

System::String::Format("{0:x}",__box(ptrUnmanagedC lass->myUnion.b_myData.bytes[2])),

System::String::Format("{0:x}",__box(ptrUnmanagedC lass->myUnion.b_myData.bytes[3])));

//NEXT RETURNS INCORRECT VALUE OF #73CB6A62
result=System::String::Format("{0:x}",__box(ptrUnm anagedClass->myUnion.myData.unmanagedLong));

return(result);
}

Sep 12 '06 #2
Ray
Mike C# wrote:
However I'm not purposely requesting that the Runtime terminate in an
"unusual way." The line that is causing me headaches is:

wcscpy(data, MyCode.c_str());
I'd suggest that you use wcscpy_s, which requires you to supply the
length of the destination string.
Where data and MyCode are defined as:

wchar_t data[256];
std::wstring AuthorCode;
My guess would be that your AuthorCode is longer than 256--I suggest you
step through your code, alternatively, cout the length of AuthorCode
just before you call wcscpy (again, wcscpy_s is a better alternative).
The strange thing is that the program appears to be running fine in Visual
Studio, but generates the error message whenever I try to run it from the
command line. Putting a try...catch block around the line in question
doesn't help - it doesn't catch the exception. I have no idea what's
causing this...
Yeah, wcscpy will just trample the end of the destination string over
without any exception. Try using wcscpy_s, and check for ERANGE (to find
out whether the size is too small for AuthorCode).

Cheers
Ray
Any ideas are appreciated!

Thanks!

Sep 13 '06 #3
Ray
Andy wrote:
wcscpy is a wide character function, and its second parameter expects a
wide character string to copy from. In your example, you are using
c_str which is not a wide character function - it returns a string of 8
bit chars.
But that c_str() belong to a wstring, so it returns a const wchar_t*

<snip>
Sep 13 '06 #4
I keep getting a strange error and can't pin it down. The message is:

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.

However I'm not purposely requesting that the Runtime terminate in an
"unusual way." The line that is causing me headaches is:
...

The strange thing is that the program appears to be running fine in Visual
Studio, but generates the error message whenever I try to run it from the
command line. Putting a try...catch block around the line in question
doesn't help - it doesn't catch the exception. I have no idea what's
causing this...
First of all, verify that there is no heap corruption or obvious stack corruption
by compiling with /GS compiler option and testing under PageHeap,
as shown here:
http://www.debuginfo.com/tips/userbpntdll.html

If none of the above reveals the problem, attach the debugger to your
application at the moment when you see the message, and check the call stack.
Probably it will tell you where the problem is.

Regards,
Oleg
[VC++ MVP http://www.debuginfo.com/]


Sep 13 '06 #5
"Andy" <an****@infotek-consulting.comwrote in message
news:11*********************@e3g2000cwe.googlegrou ps.com...
Just a guess for a starting point...

wcscpy is a wide character function, and its second parameter expects a
wide character string to copy from.
Thanks for taking a shot at it. The string is a std::wstring, so the
c_str() function is returning a const wchar_t * as far as I can tell. And
it does work when I run it in Visual Studio; it's just when I compile to an
exe and try to execute it from the command line that I get this error.

Thanks
Sep 13 '06 #6

"Ray" <ra********@yahoo.comwrote in message
news:e1**************@TK2MSFTNGP02.phx.gbl...
Mike C# wrote:
>However I'm not purposely requesting that the Runtime terminate in an
"unusual way." The line that is causing me headaches is:

wcscpy(data, MyCode.c_str());

I'd suggest that you use wcscpy_s, which requires you to supply the length
of the destination string.
I'll consider that if I can figure out the cause of the error. A basic
copy, afaik, should work. Also I've tried wcsncpy which should effectively
limit the input as well, no?
>Where data and MyCode are defined as:

wchar_t data[256];
std::wstring AuthorCode;

My guess would be that your AuthorCode is longer than 256--I suggest you
step through your code, alternatively, cout the length of AuthorCode just
before you call wcscpy (again, wcscpy_s is a better alternative).
Hmmm. Your guess there would be wrong. The AuthorCode string is L"982091",
which is far less than 256 characters. Again, it works fine when run from
Visual Studio, but gives that error when compiled to an exe and run from the
command line. That leads me to believe that the problem isn't necessarily a
coding issue on my part. But I could be wrong there too.
>The strange thing is that the program appears to be running fine in
Visual Studio, but generates the error message whenever I try to run it
from the command line. Putting a try...catch block around the line in
question doesn't help - it doesn't catch the exception. I have no idea
what's causing this...

Yeah, wcscpy will just trample the end of the destination string over
without any exception. Try using wcscpy_s, and check for ERANGE (to find
out whether the size is too small for AuthorCode).
I'll try it, but I've already verified inside Visual Studio that the length
of the string is 6 and the actual string is L"982091", indicating that the
problem doesn't lie with the code. The fact that it runs perfectly fine in
Visual Studio, but unceremoniously craps out from the command line seems to
indicate an issue somewhere else. Maybe a DLL issue or something. Perhaps
VS is loading a newer version of some DLL, while the command-line version is
loading an older less-functional version or something. Unfortunately I'm
not sure how to nail that down.

Thanks again!
Sep 13 '06 #7

"Oleg Starodumov" <com-dot-debuginfo-at-olegwrote in message
news:Op**************@TK2MSFTNGP05.phx.gbl...
>
>I keep getting a strange error and can't pin it down. The message is:

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.

However I'm not purposely requesting that the Runtime terminate in an
"unusual way." The line that is causing me headaches is:
...

The strange thing is that the program appears to be running fine in
Visual
Studio, but generates the error message whenever I try to run it from the
command line. Putting a try...catch block around the line in question
doesn't help - it doesn't catch the exception. I have no idea what's
causing this...

First of all, verify that there is no heap corruption or obvious stack
corruption
by compiling with /GS compiler option and testing under PageHeap,
as shown here:
http://www.debuginfo.com/tips/userbpntdll.html
Thanks, I'll give it a shot. The strange part is that it runs just fine in
Visual Studio IDE, but returns that error message when run from the command
line. Weird.
If none of the above reveals the problem, attach the debugger to your
application at the moment when you see the message, and check the call
stack.
Probably it will tell you where the problem is.

Regards,
Oleg
[VC++ MVP http://www.debuginfo.com/]


Sep 13 '06 #8

"Mike C#" <xy*@xyz.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
>
"Ray" <ra********@yahoo.comwrote in message
news:e1**************@TK2MSFTNGP02.phx.gbl...
Mike C# wrote:
However I'm not purposely requesting that the Runtime terminate in an
"unusual way." The line that is causing me headaches is:

wcscpy(data, MyCode.c_str());
I'd suggest that you use wcscpy_s, which requires you to supply the
length
of the destination string.

I'll consider that if I can figure out the cause of the error. A basic
copy, afaik, should work. Also I've tried wcsncpy which should
effectively
limit the input as well, no?
Where data and MyCode are defined as:

wchar_t data[256];
std::wstring AuthorCode;
My guess would be that your AuthorCode is longer than 256--I suggest you
step through your code, alternatively, cout the length of AuthorCode
just
before you call wcscpy (again, wcscpy_s is a better alternative).

Hmmm. Your guess there would be wrong. The AuthorCode string is
L"982091",
which is far less than 256 characters. Again, it works fine when run from
Visual Studio, but gives that error when compiled to an exe and run from
the
command line. That leads me to believe that the problem isn't necessarily
a
coding issue on my part. But I could be wrong there too.
The strange thing is that the program appears to be running fine in
Visual Studio, but generates the error message whenever I try to run it
from the command line. Putting a try...catch block around the line in
question doesn't help - it doesn't catch the exception. I have no idea
what's causing this...
Yeah, wcscpy will just trample the end of the destination string over
without any exception. Try using wcscpy_s, and check for ERANGE (to find
out whether the size is too small for AuthorCode).

I'll try it, but I've already verified inside Visual Studio that the
length
of the string is 6 and the actual string is L"982091", indicating that the
problem doesn't lie with the code. The fact that it runs perfectly fine
in
Visual Studio,
When running under the debugger your program ends up with the string as you
describe, but run from outside the debugger, a different codepath is taken,
which results in either a different string, or the wstring ends up not
initialized with any string.

Sep 13 '06 #9

"Code Jockey" <gi***@the.keyboardwrote in message
news:ud**************@TK2MSFTNGP03.phx.gbl...
When running under the debugger your program ends up with the string as
you
describe, but run from outside the debugger, a different codepath is
taken,
which results in either a different string, or the wstring ends up not
initialized with any string.
I ran some more tests, which is all I can do considering I cannot reproduce
the problem under the debugger. There's no explicit differentiation between
my choice of code paths under the debugger versus outside the debugger. If
a different code path is taken, process of elimination says it has to be
inside the MS MFC and Windows libraries. And I'm not eager to delve into
those. Instead I'm re-writing code to avoid as many of these functions as I
can.

Thanks.
Sep 13 '06 #10
Ray
Mike C# wrote:
I ran some more tests, which is all I can do considering I cannot reproduce
the problem under the debugger. There's no explicit differentiation between
my choice of code paths under the debugger versus outside the debugger. If
a different code path is taken, process of elimination says it has to be
inside the MS MFC and Windows libraries. And I'm not eager to delve into
those. Instead I'm re-writing code to avoid as many of these functions as I
can.
Hmm, OK--if you think that the lines that cause it are those assignment
of AuthorCode to the wstring, what if you comment out everything and
just leave that assignment? (I'm not sure how big your program is so I'm
not sure how feasible it is).

But I suppose if you just wrap those 3 lines inside a bare main(), and
compile and run it, it'll run just fine?

Also, have you put some indicator just before and just after the line
where you think it blows up, just to see that indeed it blows up on that
very line when you run the executable? e.g.:

wcout << MyCode.c_str();
wcscpy(data, MyCode.c_str());
wcout << L"My Code copied successfully!";
wcout << data;
Thanks.

Sep 14 '06 #11

"Ray" <ra********@yahoo.comwrote in message
news:e$**************@TK2MSFTNGP05.phx.gbl...
Mike C# wrote:
>I ran some more tests, which is all I can do considering I cannot
reproduce the problem under the debugger. There's no explicit
differentiation between my choice of code paths under the debugger versus
outside the debugger. If a different code path is taken, process of
elimination says it has to be inside the MS MFC and Windows libraries.
And I'm not eager to delve into those. Instead I'm re-writing code to
avoid as many of these functions as I can.

Hmm, OK--if you think that the lines that cause it are those assignment of
AuthorCode to the wstring, what if you comment out everything and just
leave that assignment? (I'm not sure how big your program is so I'm not
sure how feasible it is).
Did it, didn't work.
But I suppose if you just wrap those 3 lines inside a bare main(), and
compile and run it, it'll run just fine?
In VS it did, but not outside of VS.
Also, have you put some indicator just before and just after the line
where you think it blows up, just to see that indeed it blows up on that
very line when you run the executable? e.g.:
That's the first thing I did, and how I determined that it blew up on that
line.

wcout << L"Step 1\n";
wcscpy(data, MyCode.c_str());
wcout << L"Step 2\n";
....

The output inside VS.NET was:

Step 1
Step 2

From the command line the output was:

Step 1
This application has requested the Runtime to terminate it in an unusual
way. Please contact the application's support team for more information.
wcout << MyCode.c_str();
wcscpy(data, MyCode.c_str());
wcout << L"My Code copied successfully!";
wcout << data;
Just a follow up: I still have no idea what the problem was exactly, but I
installed VS Service Pack 1 and the newest Platform SDK, then recompiled and
it seems to run fine now from the command line. Maybe some of my files were
corrupted or something, but this seems to have fixed this particular
problem. Thanks all!
Sep 14 '06 #12

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Olaf | last post by:
I have a frameset page witch contains the myFuc() function. The function is accessed from a page in one of the frames in the frameset. An example is shown below. <input...
25
by: Neil Ginsberg | last post by:
I have a strange situation with my Access 2000 database. I have code in the database which has worked fine for years, and now all of a sudden doesn't work fine on one or two of my client's...
0
by: Kris Vanherck | last post by:
yesterday i started getting this strange error when i try to run my asp.net project: Compiler Error Message: CS0006: Metadata file 'c:\winnt\microsoft.net\framework\v1.1.4322\temporary asp.net...
6
by: Gary | last post by:
I have an application that has been working just fine for a couple of years. It queries a SQL database and returns some formatted data back to the client. I have a new client, who has a larger...
5
by: Nathan Sokalski | last post by:
When I view my index.aspx page any time after the first time, I recieve the following error: System.Web.TraceContext.AddNewControl(String id, String parentId, String type, Int32 viewStateSize)...
0
by: ivb | last post by:
Hi all, I am using DB2 8.1.11.1 on NT with ASP.NET 1.1 When application make connection to database (via ADO.NET), it set "Connection timeout" parameter to 30 seconds. After, when my webpage...
11
by: Martin Joergensen | last post by:
Hi, I've encountered a really, *really*, REALLY strange error :-) I have a for-loop and after 8 runs I get strange results...... I mean: A really strange result.... I'm calculating...
1
by: JoReiners | last post by:
Hello, I have a really strange problem. I'm unable to figure it out on my own. I parse very simple xml documents, without any check for their form. These files look very similar and are encoded...
3
by: Shelly | last post by:
I am encountering two strange problems. First one: I get a "server misconfiguration error", but only sometimes. It occurs on the first screen that accesses the database on a submit. This error...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.