RasEntry.Device null on 64bit win7

Nov 23, 2011 at 3:17 PM

Hi there,

Is there perhaps a known bug or limitation in that the RasEntry.Device is null on a windows 7 64bit edition. Other properties like Name and VpnStrategy show valid values, just the device is null. On a 32bit machine, I can use device just fine...

Thx for the help in advance... ,


Nov 24, 2011 at 12:10 AM

That's odd, it shouldn't be null. It creates the device as long as both the device name and device type are specified, which in RAS both are required for the device to be valid.

Below is an excerpt of the code that's being used with the RASENTRY structure that the Win32 API returns:

if (entry.deviceName != null && !string.IsNullOrEmpty(entry.deviceType))
    retval.Device = RasDevice.Create(entry.deviceName, entry.deviceType);

The only way I've seen the device come back null was if the device was removed from the machine before the entry was retrieved, in which case that's RAS returning nothing from the API which in turn would cause the device on the entry to be null. There was also a specific device type that didn't have a name, but it did have a device type. There might be something going on there as well. If the problem wasn't related to the device itself being removed, you might want to grab the source code and debug the RasHelper.GetEntryProperties method to see what is in the struct that comes back from the Win32 API call.

If there was a problem specific to 64-bit machines DotRas would have thrown a RasException with a 632 error code. So I'm going to make the assumption that there isn't a problem with how I have the struct defined for now, plus with as long as it was in RC2 (nearly 8 months) I'm fairly certain I would have heard about it before now. So we'll start here and see where this takes us while we try and diagnose this problem you're seeing.

Q: Was the device removed before retrieving the entry?

Q: If the device wasn't removed, grab the source code and use it to debug the problem. What was the deviceName and deviceType values on the RASENTRY struct instance being returned from the Win32 RasGetEntryProperties API call?


Nov 24, 2011 at 2:12 PM

Hi Jeff,

Thx for the reply.   Answers to your questions - no, the device was never removed. So I downloaded the source and started debugging.  In the rashelper.cs (line 945)  : 

                        int ret = UnsafeNativeMethods.Instance.GetEntryProperties(phoneBook.Path, entryName, lpRasEntry, ref lpCb, IntPtr.Zero, IntPtr.Zero);
                        if (ret == NativeMethods.SUCCESS)
                            entry = (NativeMethods.RASENTRY)Marshal.PtrToStructure(lpRasEntry, typeof(NativeMethods.RASENTRY));

                            retval = new RasEntry(entryName);


If I break @ entry = (NativeMethods.RASENTRY)Marshal.PtrToStructure(lpRasEntry, typeof(NativeMethods.RASENTRY)); line, deviceType is null & DeviceName = "WAN Miniport (IKEv2)"
I can do some more debugging if you want, but it looks like the above is where we are native GetEntryProperties is where we are having a hassle...
Nov 26, 2011 at 7:43 AM

Yeah, it looks like you might have stumbled across a bug in RAS. Couple questions for you...

Q: What's the device type that it gives you when you run it in 32-bit? I'm assuming it's "vpn" since it's using a WAN miniport.

Q: Are you able to replicate this problem on other machines besides the machine which is currently causing the issue? I'd like to know if it's isolated to that machine or if it's replicatable on other Windows 7 boxes.

Q: Also, can you call RasDevice.GetDevices on your machine and get the WAN Miniport (IKEv2) device back with the device type in 64-bit?

I'm going to continue down this path that Microsoft may have a bug in their API for 64-bit Windows for now. Once we think we've isolated the problem as much as possible, I'll open up a bug report with them so they can look into fixing it. Since we can safely assume that once the bug report is submitted we won't get a resolution for around a month, and the next service pack of Windows is quite a long ways away if it even makes it in. With that said, the best workaround I can come up with is to ensure you set the device on your entry each time you retrieve or create the entry to ensure it continues to work as expected.

Without further evidence of a bug in DotRas I'm unwilling to remove the device type null or empty check in the project because even if I did that, the entry would no longer work correctly if updated because the device would be invalid without the device type. The problems created by removing the check outweigh getting this single entry to work. I'm always open to suggestions though, if you can think of a different solution feel free to let me know.

Have a good weekend!

- Jeff

Nov 29, 2011 at 11:40 AM


I always wanted to discover my first bug in a Microsoft product.... :)

For now, I can answer the first two Q's - the 3rd one I'll do tomorrow when I can grab that 64bit machine again.

Q: What's the device type that it gives you when you run it in 32-bit? I'm assuming it's "vpn" since it's using a WAN miniport.

A. Yip - "vpn"

Q: Are you able to replicate this problem.

A. Yes, we actually seen it onsite when our app crashed. I had a gut feel it was 64bitNESS playing up, but only when I had the debugger on both 32bit/64 bit machines, it could know for sure.

For our use, we verify the virtual adapter, in case someone tampers with it... so we can reset it. I've managed to look at another property to get a similar functionality, so for now there is no crises per se. Funny that although the device is null, I can still connect with it to our vpn end point... will also double check that with Q3 for ya.

I agree with your statement - keep everything as is -let’s see what our Microsoft friends have to say!

Thanks for the assistance and help! Good job!

Nov 30, 2011 at 7:54 PM

The device is only null because of the check I have on the DotRas side ensuring the device used by the entry is valid when constructing the RasEntry object. More than likely the data exists in the phonebook, but the Win32 RAS API just isn't returning the data back to the caller. That's my theory anyway.

Dec 1, 2011 at 2:46 PM

Hi Jeff,

For Q3. - When calling RasDevice.GetDevices, I can see the WAN Miniport (IKEv2) for the device .

cheers -

Dec 6, 2011 at 12:54 AM

I was going to do some quick validation to make sure there wasn't a problem with my code before I submitted the bug to Microsoft (just to be safe), but I forgot to get a couple more bits of information from you.

Q: Which runtime version were you using? 2.0 or 4.0?

Q: Which assembly version were you using? WIN2K, WINXP, WIN2K8, or WIN7?

I think that should be all the information I need to be able to replicate the problem on my end. Once I have these last few bits of information the next steps for me would be to reproduce the problem within a 64 bit virtual machine with my product, rewrite a small solution in C++ and make sure that the Win32 APIs using the header files are causing the same behavior.

Dec 6, 2011 at 6:47 AM

Hey Jeff,


Q: Which runtime version were you using? 2.0 or 4.0?

A. 4.0

Q: Which assembly version were you using? WIN2K, WINXP, WIN2K8, or WIN7?


Jan 6, 2012 at 7:41 AM

Very interesting, I decided to take a look at this again and I was able to reproduce it before but am no longer able to. I'm using Windows 7 Ultimate 64-bit SP1.

What's the version number of %WINDIR%\System32\rasapi32.dll on the affected machines? Mine is 6.1.7600.16385 on my box right now. Kinda wish I had written down the version number when it wasn't working now that I'm not able to reproduce it.

Jan 6, 2012 at 1:05 PM

Hi Jeff. mine's the same! Windows 7 Enterprise SP1