Strange Error

[Mike C#]

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!

[Andy]

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);
}

[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!

[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>

[Oleg Starodumov]

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/]

[Mike C#]

"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

[Mike C#]

"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!

[Mike C#]

"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/]

[Code Jockey]

"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.

[Mike C#]

"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.

[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.

[Mike C#]

"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!