[RESOLVED] Converting project to UNICODE causes crashes

I used the UNICODE preprocessor directive to support UNICODE, however, doing so causes bizarre crashes.

Code:

---

"Unhandled exception at 0x7c96478e (ntdll.dll) in OUTLOOK.EXE: 0xC000000D: An invalid parameter was passed to a service or function."
 
  ntdll.dll!_RtlRaiseStatus@4()  + 0x26 bytes
  ntdll.dll!_RtlDeactivateActivationContext@8()  + 0x2b094 bytes
  kernel32.dll!_DeactivateActCtx@8()  + 0x28 bytes
  mfc80ud.dll!AfxDeactivateActCtx()  + 0x1d bytes
  mfc80ud.dll!AFX_MAINTAIN_STATE2::~AFX_MAINTAIN_STATE2()  + 0x37 bytes

---

Is there something obvious that I'm doing wrong? I don't see why using the UNICODE directive causes this problem.

Looking at the stack trace I'm guessing that the problem has to do with this line of code:

Code:

---

AFX_MANAGE_STATE(AfxGetStaticModuleState())


---

The crash occurs when I'm exiting a function in my code.

Odds are, you have a char array somewhere which you're trying to pass to a function which now wants a wchar_t array (or TCHAR). Normally the compiler would yell at you for this, but if you made the mistake of casting away the problem, it could have come back to bite you.

Unfortunately once you overwrite memory that doesn't belong to you, it's impossible to predict when the program will fail after that, so the problem isn't necessarily where the debugger thinks it is.

Quote:

---

Originally Posted by Lindley

Odds are, you have a char array somewhere which you're trying to pass to a function which now wants a wchar_t array (or TCHAR). Normally the compiler would yell at you for this, but if you made the mistake of casting away the problem, it could have come back to bite you.

Unfortunately once you overwrite memory that doesn't belong to you, it's impossible to predict when the program will fail after that, so the problem isn't necessarily where the debugger thinks it is.

---

I wish that were the case. Whoever wrote this program uses "_tstring" eveywhere which when looking at the string header file yields:

Code:

---

#ifdef _UNICODE
typedef wstring _tstring;
#else
typedef string _tstring;
#endif


---

Normally you have to use both UNICODE and _UNICODE when making a unicode app - perhaps you only defined one of them?

Good luck.

Quote:

---

Originally Posted by krmed

Normally you have to use both UNICODE and _UNICODE when making a unicode app - perhaps you only defined one of them?

Good luck.

---

Thanks, I tried that already but that doesn't help either. It's such a strange problem because when these preprocessor definitions are not defined everything works perfectly fine. This app has been around for quite a while.

I'm wondering though if there is anything special I need to do since this project is integrated with Outlook and is using MAPI.

Even though the code was written using _tstring, you need to check if it was used properly. For instance

Code:

---

_tstring mystring;
mystring = "This is my test";

---

will work fine in MBCS, but not in unicode, and

Code:

---

_tstring mystring;
mystring = L"This is my test";

---

will work in unicode but not MBCS.

This

Code:

---

_tstring mystring;
mystring = _T("This is my test");

---

would work either way.

Hope that helps.

Have you tried wrapping all of your MAPI calls with exception handlers and checking all return values for success? I don't know which MAPI calls you are using but exceptions, if implemented in the target (outlook), can potentially give you the exact reason for failure.

Take a look at this pseudo-code:

Code:

---

if(SomethingIsWrong)
  throw exception(reason)

DoSomethingFatal

return status

---

This is one typical way that exceptions are generated. Notice that the programmer has assumed that the client of this function will implement exception handling. And if not, then when something is wrong the code just continues on to a fatal error. Also note that if you catch the exception then you can simply display (or output to debugger) the reason for failure.

It is also important to check the return value for each MAPI functions. You will have to check MSDN or help files for details, but many times these functions return ERROR_SUCCESS (0) for success and a non-zero code, which can be translated to a message string, for failure.

How extensive is your debugging? I would guess that in code like this you could locate the exact MAPI call that is causing the problem. The first thing that I would do is implement exception handling and return value checking on that function call and a few around it as a start.

One other note about UNICODE strings. While it is true that you must make sure your strings are UNICODE-correct, MAPI functions, like most other COM calls, use BSTR exclusively and applications always have to convert from LPCTSTR to BSTR before the call. Make sure that your conversion from LPCTSTR to BSTR is correct.

And another thing while I think about it. After everything I wrote above about COM, something is reminding me that when I used MAPI calls to Outlook many years ago, that the interface was not COM but a dll with exported functions and the functions were implemented in ANSI only - not UNICODE. I'll check my code if I can find it, but what functions are you using? The MAPI dll exports?

FOUND THE PROBLEM!
sizeof operator is the problem and causes a stack corruption.

Incorrect:

Code:

---

TCHAR szClassName[64];
GetClassName(hwnd, szClassName, sizeof(szClassName)-1);
szClassName[sizeof(szClassName)-1] = 0;

---

TCHAR uses two bytes of storage instead of one and this is the reason why I'm receiving bizarre crashes.

Correct:
This will work in both Unicode/Non-Unicode versions.

Code:

---

TCHAR szClassName[64];
GetClassName(hwnd, szClassName, sizeof(szClassName)/sizeof(TCHAR)-1);
szClassName[sizeof(szClassName)/sizeof(TCHAR)-1] = 0;

---

Here is an article that explains it all.

http://en.wiki.mcneel.com/default.as...dkCountOf.html

Lending yet more support to my "never use sizeof to get an array length, ever, for any reason, no matter how much you want to" philosophy.

That situation would be better dealt with by declaring a constant int equal to 64, and using it in both places.