Hi...

I'm digging through some old legacy code that was written originally for
..net 1.1. It's looking for some registry entries to assemble a Sql
connection string. It wraps the registry lookup with using.

The problem is that the registry key has never existed. Under 1.1, though
the code doesn't fatally die and in 2.0 it does. This makes me think that
the behavior of using changed significantly between the revs.

The code looks something like this:

LogIt("In GetConnectionString");
using (RegistryKey hklm =
RegistryKey.OpenRemoteBaseKey(RegistryHive.LocalMa chine, TheHost))
{
using (RegistryKey subKey = hklm.OpenSubKey(
@"SOFTWARE\Foo\ConnectionInfo"))
{
string foo = subKey.GetValue("Info");
}
}
LogIt("Leaving GetConnectionString");

Under 1.1, I see the entering log message but no Leaving... message and the
rest of the code goes merrily on its way. Under 2.0, there's an unhandled
exception thrown.

It seems like the Registry stuff works the same in both 1.1 and 2.0 but
using seems to do a rethrow after managing it's resources in 2.0 while under
1.1 I have no idea what it's doing.

Thanks
Mark

Mark <mmodrall (AT) nospam (DOT) nospam> wrote:
]
Sounds like it's throwing an exception - have you tried catching
exceptions and seeing what's going on that way?

Could you post the *actual* code rather than code which is "something
like" the actual code? (For example, RegistryKey.GetValue is declared
to return object, not string.)

--
Jon Skeet - <skeet (AT) pobox (DOT) com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

Hi Mark,

In addition to Jon's reply, I also have some questions to you:
What is your application type, Winform, Asp.net or Windows Service? Do you
run this code snippet in a worker or main thread?

Have you tried to run the application under debugger? Do you get any
exceptions in .Net1.1 or 2.0? I suspect the .Net1.1 may have caught and
swallowed the registry access exception. A sample project is helpful for us
to understand and reproduce the problem.

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Hi Jeffrey...

To answer your questions, the application type is a Winform application, the
snippet I provided was being run by a button event handler in the main thread.

I tried to whip up a smaller console app to demonstrate but didn't get a
reproduction. I did get an exception thrown and propagated up the chain from
the using block.

From this I'm gathering that there may be some difference between 1.1 and
2.0 in how event handlers throwing errors deal with an exception. I'll try
to throw together a little winforms example next.

Thanks
Mark

""Jeffrey Tan[MSFT]"" wrote:

Okay, this is driving me nuts... We develop the code on 32-bit xp machines
and then deploy it to an x64 system without a debugging environment.

If I tweak the code to go down the same path it uses in production when I
run it in dev, I get unhandled exceptions thrown under 1.1 and 2.0. If I
copy the 1.1 build to the x64 system and run it, the unhandled exception is
just swallowed somewhere along the line. If I copy the 2.0 build to the x64
system and run it, the unhandled exception pops up.

The weird thing about the 1.1/x64 situation is that the snippet I posted is
about 4 calls deep in a button event handler. Obviously the Registry read is
going to blow up, but it doesn't throw all of the way out of the event
handler. The upper three call levels are able to mostly finish what they do
and populate an array list. We have some db calls (or attempts to) wrapped
in using; but no try/catch around the points where the Reg read would blow
up. I can't figure out how the 1.1 build does anything at all on the x64
environment.

It's getting to the point where I should just go ahead and fix the bug, but
it is perplexing.

thanks
Mark


""Jeffrey Tan[MSFT]"" wrote:

Okay, I think I'm making some progress here.

The registry keys I'm looking for are actually defined under the
Wow6432Node. On this system under Microsoft.Net\Framework we have 1.1 and
2.0. Under Framework64, we have only 2.0.

My guess is that when I build 1.1, the only 1.1 framework it can find is the
32-bit version so registry reads go to Wow6432Node. When I build 2.0 (Any
CPU) it goes to the main line where the key is missing, and hence all the
other problems.

From what I've read, though, shouldn't there be registry reflection that
would put this key in both registries?

Thanks
Mark

Hi Mark,

Thanks for your feedback.

Sorry, but you put too many information in three replies, and it is hard
for us to associate all the information together. Do you only get this
problem on 64bit system? Since your code logic is not very complex, can you
provide a sample project to help us reproduce it locally? This will be more
efficient for us to troubleshoot.

Thanks

Best regards,
Jeffrey Tan
Microsoft Online Community Support

Hi Jeffrey...

Sorry for the confusion with the multiple posts.

The exception being thrown in .net 2.0 and not .net 1.1 turned out to be an
artifact of the deployment environment. Because .net 1.1 only had the 32-bit
framework on the x64 box, meaning that the registry read I *thought* I was
doing was being shunted to the Wow6432node subtree. When I figured that out,
I found the key I was looking for was actually defined there.

I got the .net 2.0/x64 version working by copying those key definitions up
to the main registry as well (I also added some exception handling in my
code).

Reading up on Wow6432node, though, I saw references in the docs to the
"registry reflector" which was supposed to be keeping the registry entries in
sync, but that didn't seem to be happening. Is registry reflection only from
the main line *down* to wow6432node?

Thanks
Mark

Hi Mark,

Thanks for your feedback.

Actually, I am not a x64 programming expert. All the reflected registry
keys are documented in the link below:
"Registry Reflection"
http://msdn2.microsoft.com/en-us/library/aa384235.aspx

If your registry key did not fall into these paths, it will not be
reflected. Below is a more detailed doc:
"Registry Reflection in Windows"
http://www.microsoft.com/whdc/system...egReflect.mspx

Hope it helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support