RPC call fails with 1783 (stub received bad data)
Dave Herrmann
Studio .NET 2003. We have just upgraded our projects to Dev Studio 2005. All
the projects build fine, but when I run the client side app, the first RPC
call to the server fails with error 1783 (stub received bad data). The server
in this test was still compiled using Dev Studio 2003, but it appears the RPC
request never made it out on the network. I am using the Apr 2005 Platform
SDK, the same as was used by the Dev Studio 2003 version of the projects.
Can anyone think of a reason why simply upgrading my project to Dev Studio
2005 would break my RPC client in this way? Is there some project setting
that I'm not aware of?
Thanks for any advice.
-Dave
Brian Muth
"Dave Herrmann" <DaveHe...@discussions.microsoft.com> wrote in message news:1F4C93F2-787B-4C10...@microsoft.com...
I'm not aware of any issues along this line, but I'm curious... are you using a proxy-stub? Did you distribute the revised proxy?
Also, does this happen with any interface or method call, or a specific one?
Brian
Dave Herrmann
file.h header file, a file_s.c server source file and a file_c.c client
source file. Our client side app includes the file_c.c client source file
into its project space along with the header file. I'm not sure if that's
what you mean by a proxy-stub, but that's how we build the client side app.
This error occurs on more than one RPC function call, but not all of them. I
haven't been able to get very far in testing as the first error occurs pretty
soon and every other call more or less depends on a successful call to the
one that fails. The function that fails has an output parameter that is a
pointer to a structure that is supposed to get filled in by the server side,
but the server never sees the call. The RPC functions that are working are
not passing in any structure pointers. I know that Dev Studio has an option
to set structure alignment at 1, 2, 4, 8, 16 bytes. We have always had this
set to "default". Could the default in Dev Studio 2005 be different from the
default in Dev Studio 2003? Other than that possibility, I cannot see what
could cause this RPC failure.
The only thing we did here was to convert our project over from Dev Studio
2003 to Dev Studio 2005 and this has us really stumped.
-Dave
Brian Muth
"Dave Herrmann" <DaveHe...@discussions.microsoft.com> wrote in message news:069BC4A0-E49C-42C9...@microsoft.com...
> The IDL file is compiled by the Server project. This creates 3 stub files: a
> file.h header file, a file_s.c server source file and a file_c.c client
> source file. Our client side app includes the file_c.c client source file
> into its project space along with the header file. I'm not sure if that's
> what you mean by a proxy-stub, but that's how we build the client side app.
>
You have posted this in the ATL newsgroup, so I was assuming you are using ATL COM. I'm getting the impression that you are making
RPC calls directly? If so, I'm afraid I can't help you. Sorry.
Brian
Dave Herrmann
newsgroup to post this in that looked any better. Can you suggest a more
appropriate newsgroup for me to post to?
Just an FYI, I compared the two client stub files (file_c.c) that were
generated by running the MIDL compiler from my Dev Studio 2003 IDE and from
my Dev Studio 2005 IDE and they are different! The idl file itself is the
same in both and I am using the same midl.exe from the Platform SDK bin
folder, yet they are different. When I include the file_c.c file from my Dev
studio 2003 midl output and compile that into my Dev studio 2005 client app,
the RPC calls that were failing are now working!
This has me baffled as well. Why would the MIDL output be different in the
two invocations. I am using the same command line options in both cases, but
one is invoked from the Dev Studio 2003 IDE and the other from Dev Studio
2005 IDE.
-Dave
Alexander Nickolov
MIDL is not guaranteed to generate the same code across versions
for the same IDL.
I don't know of an RPC-specific group in the microsoft hierarchy
either. A better choice would be:
microsoft.public.win32.programmer.networks
or perhaps even:
microsoft.public.win32.programmer.ole
What you need to do, however, is to prefix your question with a
disclaimer to prevent false assumptions. Something like: I know
this question may not be for the topic of this group, but I couldn't
find a better one. I'm using RPC ... and the rest of your question
follows.
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnic...@mvps.org
MVP VC FAQ: http://vcfaq.mvps.org
=====================================
"Dave Herrmann" <DaveHe...@discussions.microsoft.com> wrote in message
news:22824D0D-C327-4697...@microsoft.com...