Prev: CreateProcessAsUser from CredProv on Vista/Longhorn Server
Next: About device class GUIDs and RegisterDeviceNotification()
From: d2walter on 9 Nov 2006 01:58
I have recently upgraded to VC 8 from Metrowerks and I am having some
trouble initializing an EXE.

I have a service and a process that is created by this service. The
child process works when it is compiled with the older compiler, but
not when it is compiled with VC 8. The service is compiled in VC 8 in
both cases. The VC 8 version also works when it is run directly - just
not when it is created by the service.

I tried removing some of the libary dependencies, but this didn't seem
to help. Any thoughts on what might be going wrong.

I was also wondering if there is any way to trap these types of
initialization problems. Because of the service and process creation,
this type of initialization error is really difficult to find. Windows
does not bring up an error message, so there was absolutely nothing to
tell what the error was until I added a WaitForSingleObject and a
GetExitCodeProcess. Even when I have this exit code, the error is
still extremely vague.

Any help would be greatly appreciated.

From: Skywing [MVP] on 9 Nov 2006 09:50
Perhaps enable "show snaps" in gflags for the app .exe in question and set
it as having a debugger associated with it (in gflags as well). Because
it's a service. you might want to specify `-server <remote-arguments>' to
start a remote debugging server for the service process that you can connect
to from an interactive context, for instance, `-server
tcp:port=12345,password=mypassword'

In almost all cases, c0000142 means that a DLL that was static linked to
your process has failed DllMain. Attaching a debugger with loader snaps
enabled should at least let you figure out which DLL is having trouble; you
have something more to go on and direct your search after you have that
information.

--
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net

<d2walter(a)gmail.com> wrote in message
news:1163055504.907777.23180(a)i42g2000cwa.googlegroups.com...
>I have recently upgraded to VC 8 from Metrowerks and I am having some
> trouble initializing an EXE.
>
> I have a service and a process that is created by this service. The
> child process works when it is compiled with the older compiler, but
> not when it is compiled with VC 8. The service is compiled in VC 8 in
> both cases. The VC 8 version also works when it is run directly - just
> not when it is created by the service.
>
> I tried removing some of the libary dependencies, but this didn't seem
> to help. Any thoughts on what might be going wrong.
>
> I was also wondering if there is any way to trap these types of
> initialization problems. Because of the service and process creation,
> this type of initialization error is really difficult to find. Windows
> does not bring up an error message, so there was absolutely nothing to
> tell what the error was until I added a WaitForSingleObject and a
> GetExitCodeProcess. Even when I have this exit code, the error is
> still extremely vague.
>
> Any help would be greatly appreciated.
>


From: d2walter on 9 Nov 2006 22:12
Many thanks for the tip about using gflags this is exremely useful for
debugging.

Unfortunately, my program works when run in the debugger. Because this
is a background process, I am using NTSD as a remote debugger server
for windbg. I am not sure if this changes anything or if there is a
better way.

Is there any way to get "show loader snaps" information without a
debugger on the process?

I am also getting the impression that this may be related to Destkop
permissions and that I may need to do some sort of CreateDesktop. Is
this necesary? I am reluctant to create a desktop for each process
this service spawns because of possible performance issues with 200-300
desktops running.

From: Skywing [MVP] on 9 Nov 2006 22:56
It is unfortunate that the debugger causes the problem to go away. You
might leave loader snaps enabled, start it without the debugger, and use
DbgView from sysinternals to see if you get any output from the process.

Insufficient permissions on the desktop or lack of desktop heap is a common
reason for user32.dll to fail initialization. In most cases user32 is
static linked to the process, so this particular problem typically manifests
itself as a c0000142. Not all c0000142 failures are necessarily related to
user32, though.

--
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net

<d2walter(a)gmail.com> wrote in message
news:1163128352.907876.72200(a)i42g2000cwa.googlegroups.com...
> Many thanks for the tip about using gflags this is exremely useful for
> debugging.
>
> Unfortunately, my program works when run in the debugger. Because this
> is a background process, I am using NTSD as a remote debugger server
> for windbg. I am not sure if this changes anything or if there is a
> better way.
>
> Is there any way to get "show loader snaps" information without a
> debugger on the process?
>
> I am also getting the impression that this may be related to Destkop
> permissions and that I may need to do some sort of CreateDesktop. Is
> this necesary? I am reluctant to create a desktop for each process
> this service spawns because of possible performance issues with 200-300
> desktops running.
>


From: d2walter on 10 Nov 2006 23:52
I have tried using DbgView, but it does not seem to work. I tried a
very simple example by setting the Image settings for calc.exe to show
loader snaps with gflags. I then ran it in the debugger to confirm
this was set properly. Ldr messages appeared as expeced. I quit the
debugger, started DbgView, and then ran calc.exe again. Nothing. I
have all the capture settings enabled in DbgView and I ran it as admin.

Do I need to do anything else like boot with /debug. When I read the
info about show loader snaps, I get the impression that I need a kernel
debugger. I also tried this kd -kl booting the system both with and
without /debug and ran calc.exe. Nothing.

I checked with Depends and found that both the old version of my
program which works and the new version which fails use the user32.dll.
Would user32.dll initialize differently depending on what it is linked
with? Along with this problem, the process that I am creating is not
going to have any desktop permissions. I still don't understand why
that would be needed for a background process.

Thank you for all the help. I have learned an immense amount about
debugging these types of problems for the future.

Dan

 |  Next  |  Last
Pages: 1 2
Prev: CreateProcessAsUser from CredProv on Vista/Longhorn Server
Next: About device class GUIDs and RegisterDeviceNotification()