This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: postinstall hang


Popper, Samuel (US SSA) wrote on 01 April 2008 21:13:

> The output of cygcheck and sc.exe are both attached to this message.
> Nothing there looked out of the ordinary to me, but I'm sure that you
> have a better idea of what to look for.

  Only a couple of things that could conceivably be relevant:

SERVICE_NAME: ACCESNT
SERVICE_NAME: NTioPCI

SERVICE_NAME: MAC_IBM
SERVICE_NAME: MAC_MOT

  These are drivers for small embedded hardware devices.  The first two go
with some kind of analog/digital io card, the second two are I think some
kind of macraigor bdm/ice box.  These kinds of small niche market products
often have drivers that are less well tested than others, and it's not
beyond imagination that they could be buggy.

  This is my prime suspect, though.

SERVICE_NAME: Sentinel
DISPLAY_NAME: Sentinel
        TYPE               : 1  KERNEL_DRIVER  
        STATE              : 4  RUNNING 
                                (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN))
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0
        PID                : 0
        FLAGS              : 

SERVICE_NAME: SNTNLUSB
DISPLAY_NAME: Rainbow USB SuperPro
        TYPE               : 1  KERNEL_DRIVER  
        STATE              : 4  RUNNING 
                                (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN))
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0
        PID                : 0
        FLAGS              : 

  Security/rights management/license control thingy of some sort.  It could
easily have been coded under the mistaken assumption that hooking process
creation is a reasonable means of tamper-proofing your software.

  Is it practical to try uninstalling and seeing if that's the cause?

> In case it's relevant, from having previously spent time staring at
> strace output, it appears that the problem is that the parent process is
> not detecting the subprocess died, rather than having the
> fork() itself fail.

  Pretty common for it to happen that way round.  I don't think we can infer
a great deal from that directly, but I could have overlooked something.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]