ShellExecute crashes Dev Studio 2008 SP 1

I have a MFC Dialog based application, and when I get a certain user-defined windows message I do the following:
ShellExecute(NULL,NULL,(const char*)WLC.Settings.FinishURL, NULL,NULL,SW_SHOW);

That FinishURL is just a basic CString. Anyway, this causes Dev Studio 2008 to crash. I can rum my app stand alone by going into the build folder and running the debug or release version and it runs just fine.

I know this is a long shot, but does anyone know why this is crashing Dev Studio 2008 and how I can fix it? I have since added some #ifndef DEBUG around it, but I would rather it actually execute while I am testing.

I have no idea, but FWIW, you don't need to cast a CString to a const char*. It has an overloaded operator for that.

Are you saying VIsual Studio itself is crashing, or your app is crashing inside the debugger?

Could you give us some more information? Like what kind of 'crash' are you getting and what the call stack looks like? Have you tried debugging to see if any of the variables contain garbage data when making the call?

1. Is it so hard to use Code tags and white spaces between the argument list? Doesn't it look better:
   Code:

   ---

   ShellExecute(NULL, NULL, (const char*)WLC.Settings.FinishURL, NULL, NULL, SW_SHOW);

   ---

   :confused:
2. What is the purpose to cast "CString" to const char* type?
3. Is your build causing the crash an ANSI or UNICODE?
4. How does the message handler look like?
5. What exactly does this CString contain?
6. Do you by chance make some GetBuffer without the following ReleaseBuffer?

Dev Studio is crashing. Not my application. I can't look at the call stack because the development environment crashes.

2. To make sure I get the char * type of pointer. CString does this with a cast. I just want to make sure I end up with a pointer to a buffer of *char and not a reference to an object.
3. I am using ANSI, the build works fine, the app runs until it hits that statement then Dev Studio crashes. Not my App, but the development environment.
4. Message Handler hook?
5. It constains, "https://www.google.com". You can launch URLs this way and it will use the default system web browser.
6. No.

Quote:

---

Originally Posted by DeepT

2. To make sure I get the char * type of pointer. CString does this with a cast. I just want to make sure I end up with a pointer to a buffer of *char and not a reference to an object.

---

Then, please, read the post from GCDEF. :cool:

Did you try to rebuild your project, ... to delete .ncb, .opt, .aps and so on files?
To restart Windows?

Quote:

---

Originally Posted by DeepT

5. It contains, "https://www.google.com". You can launch URLs this way and it will use the default system web browser.

---

We can't see what's behind those variables, so do this -- hardcode into the call of ShellExecute that string. Does it crash then?

Or even do this -- declare a CString right before the call and set it to the string:

Code:

---

CString whatever = "https://www.google.com";
ShellExecute(... whatever, ...);

---

If these do not crash, then the suspicion is that you've corrupted the CString object in some way, or the CString doesn't contain the string you say it contains. If the "whatever" version crashes, then there still is a suspicion of corruption (since CString uses reference counting).

Quote:

---

I can rum my app stand alone by going into the build folder and running the debug or release version and it runs just fine

---

Means very little, seriously. Many buggy app can "run fine" when run under one circumstances, but when run under the debugger, or another computer, then all heck breaks loose. C++ isn't Java or C#, where if you make a mistake, you're guaranteed some sort of diagnostic to be produced.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by DeepT

Dev Studio is crashing. Not my application. I can't look at the call stack because the development environment crashes.

---

Do you mind to explain what is Dev Studio? Is it Visual Studio? Or something else?

I am Visual Studio 2008.
I tried this:

Code:

---

CString URL = "https://www.google.com";
                ShellExecute(NULL,NULL,(const char*)URL, NULL,NULL,SW_SHOW);

---

and this also crashes Visual Studio 2008. Putting in the string directly in place of the CString works without a crash.

However, even this:

Code:

---

CString URL = "https://www.google.com";
                char *str = (char *)(const char *)URL;
                ShellExecute(NULL,NULL,str, NULL,NULL,SW_SHOW);

---

Crashes Visual Studio 2008. I put a break point into the call and str does point at the correct string.

Quote:

---

Originally Posted by DeepT

I am Visual Studio 2008.
I tried this:

Code:

---

CString URL = "https://www.google.com";
                ShellExecute(NULL,NULL,(const char*)URL, NULL,NULL,SW_SHOW);

---

and this also crashes Visual Studio 2008. Putting in the string directly in place of the CString works without a crash.

---

If the build is Unicode, those casts are incorrect. As a matter of fact, why are you doing all of those C-style casts to begin with?

Any time I see casting all over the place like that, it gives the indication that the code would never have compiled unless you forced the compiler to keep quiet by casting. So to be honest with you, I am not surprised the call crashes or the string being pointed to is not correct.

The ShellExecute function takes LPCTSTR as the string parameters, not const char*. This very simple example should have worked:

Code:

---

LPCTSTR URL = _T("https://www.google.com");
ShellExecute(NULL,NULL, URL, NULL,NULL,SW_SHOW);

---

Notice the _T() macro?

Then create a brand new program, and just these two lines:

Code:

---

CString URL = _T("https://www.google.com");
ShellExecute(NULL,NULL, (LPCTSTR)URL, NULL,NULL,SW_SHOW);

---

The reason why you should try this with an untouched, new program is because CString can get corrupted due to it being a reference counted type. If you've messed up the reference counting in some way, then all bets are off.

Regards,

Paul McKenzie

Seriously, stop casting CStrings to const char*. Here's why you don't need to.

http://msdn.microsoft.com/en-us/libr...=vs.60%29.aspx

I know that's not the problem here, but it's an unnecessary habit you should get out of.

I'd also try to replace the second NULL with the _T("open") verb.

Ok, this code block also crashes Dev Studio 2008 and has nothing to do with CStrings:

Code:

---

#define URL "https://www.google.com"

                int Len = strlen(URL);
                char Buff[1024] = {0};
                CopyMemory( &Buff[0], URL, Len );
                ShellExecute(NULL,_T("open"),Buff, NULL,NULL,SW_SHOW);

---

Just that in an application by itself?

No, i didn't try that in an application by itself. It is final step in my other app. I could paste that into a new app. If it crashes or does not, what does that tell me? Note this is crashing the development environment. My application, if you run it outside of the development environment runs just fine and launches the URL correctly. I want to know why this call causes my development environment to crash.

Ok, I just created a new MFC Dialog based project. On Init dialog I put that code (in my last post). It ran fine and did not crash Dev Studio 2008.

Quote:

---

Originally Posted by DeepT

Ok, this code block also crashes Dev Studio 2008 and has nothing to do with CStrings:

Code:

---

#define URL "https://www.google.com"

                int Len = strlen(URL);
                char Buff[1024] = {0};
                CopyMemory( &Buff[0], URL, Len );
                ShellExecute(NULL,_T("open"),Buff, NULL,NULL,SW_SHOW);

---

---

This code is wrong! :thumbd:
Please, try what Paul suggested:

Quote:

---

Originally Posted by Paul McKenzie

Then create a brand new program, and just these two lines:

Code:

---

CString URL = _T("https://www.google.com");
ShellExecute(NULL,NULL, (LPCTSTR)URL, NULL,NULL,SW_SHOW);

---

---

Ok, VictornN, I tried that exact code you pasted and it crashes Dev Studio 2008 in my project.

This code:

Code:

---

CString URL = _T("https://www.google.com");
ShellExecute(NULL,NULL, (LPCTSTR)URL, NULL,NULL,SW_SHOW);

---

Quote:

---

Originally Posted by DeepT

Ok, this code block also crashes Dev Studio 2008 and has nothing to do with CStrings:

---

That code is wrong if it's a Unicode app.

Not only should you get out of the habit of casting, get into the habit of using _T(), TEXT(), TCHAR, etc. instead of char, char*, etc. Also, your "CopyMemory" would be wrong, since CopyMemory takes the number of bytes, not the number of characters. A Unicode app has 2-byte characters, not 1 byte.

I know you say you're using ANSI, but mistakes like this gives the impression you may be making mistakes in other places in your app, causing memory corruption in some way.,

Code:

---

TCHAR Buff[1024] = _T("https://www.google.com");
ShellExecute(NULL,_T("open"),Buff, NULL,NULL,SW_SHOW);

---

This code should work, regardless of the build type.

Regards,

Paul McKenzie

It is not unicode. Anyway Ill just put the debug macros around it and not execute it in my development environment. My app runs just fine when run stand-alone.

Quote:

---

Originally Posted by DeepT

Anyway Ill just put the debug macros around it and not execute it in my development environment. My app runs just fine when run stand-alone.

---

That is not a fix. If your app ran great on one computer and flunked out on another, do you throw the computer away where your application fails, so as to "fix the bug" and say "it works on my main machine, so it's OK"? Honestly, that "fix" you came up with would be totally unacceptable in a professional environment.

As I stated previously, if a C++ application has a bug, there is no guarantee how it will run. You need to figure out exactly why mysteriously your CStrings are corrupted. If a simple ShellExecute of a web address were so buggy, then it would have been reported by hundreds if not thousands of programmers.

Regards,

Paul McKenzie

Remember it's not his app that's crashing, it's Visual Studio. Nothing in his code should be able to cause that. It is possible that there's nothing wrong with his code at all.

I have the same thing happening. Nothing to do with the code, it's Visual Studio bug.

Nikita Leontiev
Just Manager Developer

strlen does not include the the null-termination so your copy wont be null-terminated. See http://msdn.microsoft.com/en-us/library/78zh94ax.aspx
Edit: Sorry, I didnt account for your init

(Two years later...)

I was having this problem, too, but I solved it by making the following change.

From this:

Code:

---

CFile htmFile;
CString strFileName = _T("C:\\Temp\\TempHTML.htm");

if ( htmFile.Open(strFileName, CFile::modeCreate | CFile::modeWrite | CFile::shareDenyWrite )
{
    // Write stuff to the file
    ...

    htmFile.Flush();  // I put the Flush in as a test to see if it would help, but it didn't. I left it in anyway.
    htmFile.Close();

    ::ShellExecute(NULL, _T("open"), strFileName, NULL, NULL, SW_SHOW);  // VS crashes here in Debug only
}

---

To this:

Code:

---

CFile htmFile;
CString strFileName = _T("C:\\Temp\\TempHTML.htm");

BOOL rc = htmFile.Open(strFileName.GetBuffer(), CFile::modeCreate | CFile::modeWrite | CFile::shareDenyWrite);
strFileName.ReleaseBuffer();

if ( rc )
{
    // Write stuff to the file
    ...

    htmFile.Flush();
    htmFile.Close();

    ::ShellExecute(NULL, _T("open"), strFileName, NULL, NULL, SW_SHOW);  // This works in Debug & Release
}

---

Apparently, CFile::Open must be holding onto something vital in the CString.