Issues with 64-bit

Coordinator
Oct 23, 2008 at 8:21 PM
This is the most frequent complain we receive with regards to SQLH2.
It reports it cannot find native 64-bit instances on 64-bit OS (typically Windows 2003 SP2).
Looking back we didn't have many complaints before SP2, but that didn't mean they were not there.
I tried to debug the issue in my local environment (set up Win2003 SP2 OS nad installed SQL Server 2005 64-bit there). It worked. So I didn't know where to look.
Since the code was published on CodePlex I have been asking people to debug their 64-bit issues in their local environment. So far I haven't received any bug reports, but it's too early.
If you encountered this issue and made it work please share what you did to make it work.
If you experience that issue in your current environment I would ask you to try debugging it.
I hope together we can get to the root of the problem.
Oct 31, 2008 at 10:55 AM
Edited Oct 31, 2008 at 10:56 AM
The lastert version fixed for me the issue of finding 64bit instances but it is now having another issue that I posted in the issue tracker.
Coordinator
Nov 19, 2008 at 11:06 PM
The issue you refer to I believe is fixed. (See the source code tab).
Unfortunately I didn't get to publish msi from fixed code.
I have had problems with my machine (reimaged machine, while simultaneously loosing backup drive). I'll publish fixed release when I get to it.
Dec 1, 2008 at 4:54 PM
Consistently noticed the same in my environment across all servers.  Using build v.2.1.001.  Note the following in the error log for each server where this applies...

Status:  Scanning Registry on xxxxxxx
WARNING:  No SQL Server instances registered on the box

Is there a solution to this?
Dec 8, 2008 at 11:30 PM
I think the problem is with                 m_hklm = RegistryKey.OpenRemoteBaseKey (RegistryHive.LocalMachine, m_target_machine);

This class seems to open up only the 32bit registry on remote systems when run from a 32bit system.  I think we need some way to determine if a remote host is 32bit/64bit and then grab the correct portion of the registry in order to enumerate the instances. On a 64bit system you won't have any instance information listed in the 32bit portion of the registry.

I found this article about this issue http://blogs.msdn.com/cumgranosalis/archive/2005/12/19/Win64RegistryPart2.aspx but i don't really know how to incorporate this into SQLH2 yet.




Dec 15, 2008 at 1:34 PM
Strange thing... I compiled the code and it ran fine, but the binary download from this site seems to have the issue.  Not sure why.  Anyway its working now.
Mar 19, 2009 at 5:34 PM
I've installed the latest stable build on a 32-bit Win2003 server; it still says that on 2 64-bit Win2003 servers there are no instances of SQL Server installed.
Can anyone help me out?

Many thanks in advance,

Jan Borrius
Mar 27, 2009 at 3:24 PM

Update:
We've even tried installing version V2.1.004 on a 64-bit Win2003 & 64-bit SQL Server 2005, but when running SQLH2, the logfile says that there are no SQL Server instances installed on this server. We are running with a default instance on this server.

Could it be that in this case there is something wrong with the registry settings?

Any help would be appreciated.

Kind regards,

Jan Borrius

Coordinator
Mar 31, 2009 at 1:23 AM

It actually depends on the client OS. Some clients get routed to WoW32 portion of the registry. Some connect to the root. I had an impression that WinXP, for example, is able to discover 64-bit instances when connected to 64-bit OS.

Ultimately it has to be fixed on the code level to make it aware of duality of 64-bit OS'es. The path referenced above doesn't seem to be an easy one. I will investigate WMI option at some point (when I have time).