Problems with VariantChangeType

I have posted several problems which are all related to OLEAUT creating a
window and a thread. I have come to the following conclusion.

My situation: I have a simple application that performs a VariantChangeType
to change a floating point string into a floating point value. Upon
invokation of VariantChangeType it appears OLEAUT DLL launches a thread and
this thread creates a window. Afterwards my application terminates, by
design. During the process unload I get an ACC-VIO. This ACC-VIO is due to
the fact that the thread created by the VariantChangeType does not terminate
before process unload. I have tried calling CoInit and CoUninit without any
success.

My research: After figure my problem was with VariantChangeType, I did some
searching and found this MSDN article "
PRB: Oleaut32 Hidden Window Blocks Apps Broadcasting Messages
" This article explained everything I have been seeing for some time. I am
assuming MS solution to this problem was to launch a thread which is the one
I am seeing.

Conclusion: On PC based Windows OSs the MS solution will work (i.e.,
launching a thread upon VariantChangeType invokation). However, for CE the
solution will not work. The reason is because of the following
-) PC based platforms (XP, 2K) All threads are terminated before a process
unloads
-) CE platforms a process can unload without all threads being terminated.
I have proof of this in other poorly written applications.

Solution: Currently, I rewrote VariantChangeType and I never get an
ACC-VIO.

Questions:
-) Are my conclusions in correct or is there something my app is doing
incorrectly?
-) Is there a patch?
-) If I am correct and MS has not fixed it, how do I let them know about it
so it may be fixed for others?


Thanks

Jim
Wed May 05 14:16:25 CDT 2004

troy anderson wrote:
> My situation: I have a simple application that performs a =
VariantChangeType
> to change a floating point string into a floating point value. Upon
> invokation of VariantChangeType it appears OLEAUT DLL launches a =
thread and
> this thread creates a window. Afterwards my application terminates, =
by
> design. During the process unload I get an ACC-VIO. This ACC-VIO is =
due to
> the fact that the thread created by the VariantChangeType does not =
terminate
> before process unload.=20

Which version of CE is this? I can't seem to reproduce it on either =
Pocket PC 2002 or CE 4.2. I created a skeleton app and added the =
following code to WinMain:

VARIANT v;
VariantInit(&v);
v.vt =3D VT_BSTR;
v.bstrVal =3D SysAllocString(L"3.1415");
VariantChangeType(&v, &v, 0, VT_R4);

No thread is created by VariantChangeType and there is no access =
violation on exit. Are you doing anything significantly different to =
this?

--=20
Jim Barry, MVP for Windows SDK

troy
Fri May 14 05:37:51 CDT 2004

I am using CE 4.2 with an OS I put together. My code uses _variant_t and
_bstr_t which does the same as your example. I know it is a thread in OLE
because using a process spy I am able to see this thread has a window
associated with it the window name is "OLEAUT" or some variant of that name.
I found an article MS published years ago Q189427 which states a problem and
a solution which looks like what is happening on my platform. I think the
solution stated by in this article is what MS did in CE to get around the
problem. However, it poses another problem for my platform.

"Jim Barry" <jim@mvps.org> wrote in message
news:eE3L3VtMEHA.3944@tk2msftngp13.phx.gbl...
troy anderson wrote:
> My situation: I have a simple application that performs a
VariantChangeType
> to change a floating point string into a floating point value. Upon
> invokation of VariantChangeType it appears OLEAUT DLL launches a thread
and
> this thread creates a window. Afterwards my application terminates, by
> design. During the process unload I get an ACC-VIO. This ACC-VIO is due
to
> the fact that the thread created by the VariantChangeType does not
terminate
> before process unload.

Which version of CE is this? I can't seem to reproduce it on either Pocket
PC 2002 or CE 4.2. I created a skeleton app and added the following code to
WinMain:

VARIANT v;
VariantInit(&v);
v.vt = VT_BSTR;
v.bstrVal = SysAllocString(L"3.1415");
VariantChangeType(&v, &v, 0, VT_R4);

No thread is created by VariantChangeType and there is no access violation
on exit. Are you doing anything significantly different to this?

--
Jim Barry, MVP for Windows SDK

Jim
Fri May 14 13:26:15 CDT 2004

troy anderson wrote:
> I am using CE 4.2 with an OS I put together. My code uses _variant_t =
and
> _bstr_t which does the same as your example. I know it is a thread in =
OLE
> because using a process spy I am able to see this thread has a window
> associated with it the window name is "OLEAUT" or some variant of that =
name.

OK, using Remote Process Viewer I now see a second thread that is =
created by the call to VariantChangeType. Before, I was looking at the =
'Threads' window in EVC which only showed the one thread (suddenly I =
trust the EVC debugger even less than I already did). However, using the =
Remote Spy, I still don't see an OLEAUT window. Are you using Remote =
Spy, or something else? I still don't get the crash on exit either - can =
you post a repro case?

> I found an article MS published years ago Q189427 which states a =
problem and
> a solution which looks like what is happening on my platform.

It certainly looks relevant. Have you considered delving into the CE =
source?

--=20
Jim Barry, MVP for Windows SDK

troy
Sat May 15 05:53:14 CDT 2004

The tool I am using is Entrek's ProcMan.

Here is a code snipet from a method that produces it all of the time when a
registry key contains a string that represents a floating point number.

//
//get_Value. This method will return a value associated with this key
//and value name pair
//
// Arguments:
// HKEY Handle Handle to a currently open key
// _bstr_t Key The name of the key
// _bstr_t *pValName The name of the value. If NULL, then
// the value is retrieved from the key.
//
// Exceptions:
// none
//
// Return:
// _variant_t The value
//
_variant_t CRegistryServices::get_Value(HKEY Handle, _bstr_t &Key, _bstr_t
&ValName)
{
DEBUG_METHOD("get_Value");
HKEY hKey=NULL;
LONG lStat=0;
_variant_t v;

TRY {

//Open Registry Key
_bstr_t KeyName = (m_bRelative) ? m_ServiceKey + Key : Key;
#ifdef _WIN32_WCE
ULONG ulStat = RegOpenKeyEx(Handle, KeyName, NULL, NULL, &hKey);
#else //_WIN32_WCE
ULONG ulStat = RegOpenKeyEx(Handle, KeyName, NULL, KEY_READ, &hKey);
#endif //_WIN32_WCE
if (ERROR_SUCCESS != ulStat) THROW(ulStat)

ULONG lValType=0;
TCHAR pszValName[256], pszVal[256];
ULONG lValSize=sizeof(pszVal);

memset(pszValName, 0, sizeof(pszValName));
memset(pszVal, 0, sizeof(pszVal));
if (ValName.length()) _tcscpy(pszValName, (TCHAR *) (ValName));
ulStat = RegQueryValueEx(hKey, pszValName, NULL, &lValType, (UCHAR *)
pszVal, &lValSize);
if (ERROR_SUCCESS != ulStat) THROW(ulStat)

switch(lValType) {
case REG_DWORD:
v = (LONG) (*((LONG *) pszVal));
break;
case REG_SZ:
case REG_MULTI_SZ:
case REG_EXPAND_SZ:
v = _bstr_t(pszVal);
break;
default: {
char *pbData=NULL;
SAFEARRAYBOUND rgsabound[1];
rgsabound[0].lLbound = 0;
rgsabound[0].cElements = lValSize;
SAFEARRAY *psa = SafeArrayCreate(VT_I1, 1, rgsabound);
SafeArrayAccessData(psa, (void **) &pbData);
memcpy(pbData, pszVal, lValSize);
SafeArrayUnaccessData(psa);
v.vt = VT_I1|VT_ARRAY;
v.parray = psa;
break;
}
}

}
CATCHEX(lStat);

if (hKey) {RegCloseKey(hKey); hKey=NULL;}
return v;
}

Note: I can even comment out the registry access and simply place in the
return variant a "3.24244" via = operator and it produces the problem.

I have delved into the source code for some time now. Problem is MS did not
provide sources for OLE32.DLLand OLEAUT.DLL. There are no registered
DEBUGZONES either. I have posted several other question related to what I
have been able to figure out via call stacks but not response to them.
Perfect example is I see CoSetState in the call stack which is used to init
some things. In the on-line help it states this is not implemented.
However, it is in my image because I see several other function called by
this routine. Similarly, I see GetAppData which I have inquired about but
no replies. I really wish I had some sources to rummage through to figure
this out.

What is strange is I have been able to repeat this problem in several other
CE (4.2) images I have put together. The problem consistantly appears to
occur with CE.NET 4.2. However, for CE.NET 4.1 and PPC 2000 everything
works OK (i.e., there is no problem).

If I replace VariantChangeType with my own implentation of
VariantChangeType, everything works great. My implementation simply
performs all of the data type conversions for float and long in the same
thread as the caller. All other data types I pass onto MS's implementation.

I appreciate your help.

"Jim Barry" <jim@mvps.org> wrote in message
news:OGPxyDeOEHA.628@TK2MSFTNGP11.phx.gbl...
troy anderson wrote:
> I am using CE 4.2 with an OS I put together. My code uses _variant_t and
> _bstr_t which does the same as your example. I know it is a thread in OLE
> because using a process spy I am able to see this thread has a window
> associated with it the window name is "OLEAUT" or some variant of that
name.

OK, using Remote Process Viewer I now see a second thread that is created by
the call to VariantChangeType. Before, I was looking at the 'Threads' window
in EVC which only showed the one thread (suddenly I trust the EVC debugger
even less than I already did). However, using the Remote Spy, I still don't
see an OLEAUT window. Are you using Remote Spy, or something else? I still
don't get the crash on exit either - can you post a repro case?

> I found an article MS published years ago Q189427 which states a problem
and
> a solution which looks like what is happening on my platform.

It certainly looks relevant. Have you considered delving into the CE source?

--
Jim Barry, MVP for Windows SDK

troy
Wed May 19 14:26:12 CDT 2004

I just took your example and changed it to match more of what happens inside
_bstr_t and _variant_t. I also changed it to convert from double to BSTR.
See code frag below
{
VARIANT v, d;
VariantInit(&v);
VariantInit(&d);

v.vt = VT_R8;
v.dblVal = 3.1415;
VariantChangeType(&d, &v, 0, VT_BSTR);
BSTR b=SysAllocString(d.bstrVal);

VariantClear(&v), VariantClear(&d);
if (b) SysFreeString(b);
}

The problem occurs. Does it occur on your platform?


"Jim Barry" <jim@mvps.org> wrote in message
news:OGPxyDeOEHA.628@TK2MSFTNGP11.phx.gbl...
troy anderson wrote:
> I am using CE 4.2 with an OS I put together. My code uses _variant_t and
> _bstr_t which does the same as your example. I know it is a thread in OLE
> because using a process spy I am able to see this thread has a window
> associated with it the window name is "OLEAUT" or some variant of that
name.

OK, using Remote Process Viewer I now see a second thread that is created by
the call to VariantChangeType. Before, I was looking at the 'Threads' window
in EVC which only showed the one thread (suddenly I trust the EVC debugger
even less than I already did). However, using the Remote Spy, I still don't
see an OLEAUT window. Are you using Remote Spy, or something else? I still
don't get the crash on exit either - can you post a repro case?

> I found an article MS published years ago Q189427 which states a problem
and
> a solution which looks like what is happening on my platform.

It certainly looks relevant. Have you considered delving into the CE source?

--
Jim Barry, MVP for Windows SDK