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: When ssh'd in, cannot run MS compiler /Zi debug option.

On Jul 19 04:06, Mark Charney wrote:
> I suspect I'm missing some "rights".  This is an issue for me 
> on multiple machines running  Windows Server 2003 x64 or for 
> 32b WinXP.
> When I try to compile using the debug-option (/Zi) to the 
> Microsoft Visual Studio Pro 2005 compiler:
>     cl /Zi hello.cpp
> it only works from within cygwin if I am on the console or 
> remote desktop. If I ssh-in to the same machine, it fails with 
> a error message:
>      Fatal Error C1902: Program database manager mismatch; please 
>      check your installation.
> Compiling without /Zi works fine anywhere we try it. My best guess is 
> that it has to do with some RPC rights required for the debug-symbol 
> file (PDB) generation done by the mspdb80.dll . That DLL uses RPC to 
> talk to the mspdbsrv.exe. 
> Any ideas?

Yes.  I assume the problem is an authentication check in the Visual
Studio applications.  When you login via ssh with pubkey authentication,
you're running in the logon session of the user which is running the
sshd service.  In case of 2K3 this should be the sshd_server account,
in case of XP it would be the SYSTEM account.

The problem is that there's arguably an identification bug in Windows.
Try "/cygdrive/c/WINDOWS/system32/whoami.exe" and you will see that
you're identified as "sshd_server", not as yourself.

The strange Windows behaviour is that the native identification
functions always return the user name of the logon session, not the user
which is stored in the user token attached to the process.  Would the
latter be the case, you would be correctly identified, but, alas!

I have a patch in the loop which would allow to change this, but it
wouldn't help for the 64 bit Windows since it requires to build a DLL in
64 bit mode (you know the problem I assume ;-))

What you can do is this:

Either use password authentication instead of public key authentication
when loging in through ssh.  Password authentication creates a valid
logon session, so you're correctly identified and the problem should go

Or, if you don't want to use password authentication, you could try
if there's a way to add the user account sshd_server resp. SYSTEM to
the list of users which can access the "Program database", whatever
that is.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Unsubscribe info:
Problem reports:

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