This is the mail archive of the
mailing list for the Cygwin project.
Re: When ssh'd in, cannot run MS compiler /Zi debug option.
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Wed, 19 Jul 2006 11:14:26 +0200
- Subject: Re: When ssh'd in, cannot run MS compiler /Zi debug option.
- References: <loom.20060719T053158firstname.lastname@example.org>
- Reply-to: cygwin at cygwin dot com
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
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html