Re: creating Out-of-proc server in wince 6.0

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Thanks Paul. The problem was actually with proxy.c, as when we built the
proxy.dll with timeserver_p.c, timeserver_i.c and dlldata.c separately
included in it, then it just worked just fine. Actually there was some
statement like

#pragma data_seg(".rdata")

in timeserver_p.c whose scope was getting over to other files and causing
data access problems.

As of now, we are able to get interface to the ITimeserver and also do query
interface and addref etc.

Now, when we try to call our defined function GetTime() using interface to
ITimeserver
we are able to print MessageBox, and reach till CTimeServer::GetTime()3

but after that, the program gives

40925 PID:5170006 TID:5180006 Exception 'Raised Exception' (-1): Thread-
Id=05180006(pth=94b89abc), Proc-Id=05170006(pprc=94b897a4) 'SERVER0309.EXE',
VM-active=05170006(pprc=94b897a4) 'SERVER0309.EXE'
40925 PID:5170006 TID:5180006 PC=40026d58(coredll.dll+0x00016d58)
RA=8008d49c(kernel.dll+0x0000649c) SP=0002f680, BVA=00000000
40951 PID:5170006 TID:5180006 Exception 'Raised Exception' (-1): Thread-
Id=05180006(pth=94b89abc), Proc-Id=05170006(pprc=94b897a4) 'SERVER0309.EXE',
VM-active=05170006(pprc=94b897a4) 'SERVER0309.EXE'
40953 PID:5170006 TID:5180006 PC=40026d58(coredll.dll+0x00016d58)
RA=8008d49c(kernel.dll+0x0000649c) SP=0002fa74, BVA=00000000
40969 PID:5170006 TID:5180006 Exception 'Data Abort' (4): Thread-Id=05180006
(pth=94b89abc), Proc-Id=05170006(pprc=94b897a4) 'SERVER0309.EXE', VM-
active=05170006(pprc=94b897a4) 'SERVER0309.EXE'
40970 PID:5170006 TID:5180006 PC=40549660(rpcrt4.dll+0x00019660)
RA=405495bc(rpcrt4.dll+0x000195bc) SP=0002fb64, BVA=00000000
40987 PID:400002 TID:5180006 Exception 'Raised Exception' (-1): Thread-
Id=05180006(pth=94b89abc), Proc-Id=00400002(pprc=80fdf308) 'NK.EXE', VM-
active=05170006(pprc=94b897a4) 'SERVER0309.EXE'
40989 PID:400002 TID:5180006 PC=c003b68c(k.coredll.dll+0x0001b68c)
RA=8008d49c(kernel.dll+0x0000649c) SP=d0e9f558, BVA=ffffffff


The definition of GetTime is as follows:

STDMETHODIMP CTimeServer::GetTime(TCHAR* lpszTime ,int iCount)
{
GEODBG((L"\nEntry CTimeServer::GetTime()"));
if( lpszTime == NULL)
return S_FALSE;

TCHAR _szTime[100];
SYSTEMTIME sTime;
GetSystemTime(&sTime);
GEODBG((L"\nEntry CTimeServer::GetTime()1"));
// GeoDebug is just a macro to display in output window
wsprintf(_szTime,L" %02d-%02d-%04d/%d:%02d", sTime.wDay,sTime.wMonth,
sTime.wYear,sTime.wHour,sTime.wMinute);
GEODBG((L"\nEntry CTimeServer::GetTime()2"));
GEODBG((L"%d", iCount));
MessageBox(NULL, lpszTime, L"Input",MB_OK);
wcsncpy(lpszTime, _szTime,iCount);
MessageBox(NULL, _szTime, L"Time",MB_OK);
GEODBG((L"\nEntry CTimeServer::GetTime()3"));
return S_OK;
}

Client calls the GetTime function in the following way:

HRESULT hr1 = lpCF->CreateInstance(NULL , IID_ITimeServer , (LPVOID*)
&lpTimeServer);

if(hr1 == S_OK) OutputDebugString(L" Create Instance TimeServer
Success\n");

if(hr1 == S_OK)
{
TCHAR* lpStr = (TCHAR*) malloc( 100 * sizeof(TCHAR));
HRESULT hr3 = lpTimeServer->GetTime(lpStr,100);
if(hr3 == S_OK)
MessageBox(NULL, lpStr,L"Title", MB_OK);
}


Is there something wrong with the way we are defining GetTime() or the
problem is still in communication between the server and the client?

Regards
Pranay




Paul G. Tobey wrote:
I think you're trying too hard. Don't create proxy.c. Build your dll with
just timeserver_p.c, timeserver_i.c and dlldata.c in it. What happens when
you deploy that DLL to the device? It seems that you should get some sort
of notification that it has been registered. If not, DON'T GO TO SOME OTHER
REGISTRATION METHOD. If registration does not work, something is seriously
broken; fix it.

Also, don't choose a generic name, like proxy.dll for your proxy. Think
someone else might do that? What would happen if there were two? They're
probably both in \windows, with the same filename, so one of them will be
lost and the wrong one called for any proxies originally set up to use that
one. TimeServerProxy.dll is a much better name.

Finally, you've verified the exports needed to register the DLL, but have
you verified the parameters? Remember that name mangling in C++ can cause
your DLL to export perfectly valid functions that will never be called
because their names include parameter type information, C++ style, but
that's not what the COM support is looking for.

Paul T.

Hi Paul
Thanks for the quick reply. The way we build the proxy is as follows:
[quoted text clipped - 95 lines]
Please help
Pranay

--
Message posted via http://www.pocketpcjunkies.com

.

Relevant Pages

  • Re: I have to reboot every time I recompile
    ... Services has an interface for starting and stopping services. ... Paul T. ... located on the Win CE device, it runs the DLL ... I think a soft reboot ...
    (microsoft.public.windowsce.embedded)
  • Re: DLL registering problem in WinCE..
    ... The *interface* wouldn't be in the registry. ... Use debug messages to see what pieces of your DLL ... >> Paul T. ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: CreateFile api call failing
    ... Paul T. ... NDISUIO and use that to send OIDs to the driver. ... hence i m trying to open the interface to get a valid handle. ...
    (microsoft.public.windowsce.app.development)
  • Re: Random file access -cont
    ... That helps, thanks Paul! ... > You can call anything in any DLL anywhere on the device, ... > Download the OpenNETCF SDF and look through the source code. ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Exporting classes
    ... Paul T. ... We know nothing about what this DLL is ... Chris Tacke, Embedded MVP ... #define EXPORTMODIFICATION declspec ...
    (microsoft.public.windowsce.embedded.vc)