Connectivity Driver on x64 systems

spcentralspcentral Registered User, Hog Beta
I am having trouble getting the Wholehog Connectivity Driver correctly working on my x64 machine. I have tried un-installing & re-installing, but no luck. Any help will be great.

Thanks!

Comments

  • cmuenchowcmuenchow Registered User, Administrator, HES Staff
    edited July 2010
    What visualizer are you using and what is the failure you are experiencing?
  • spcentralspcentral Registered User, Hog Beta
    edited July 2010
    I am using ESP Vision. Here is a screenshot of the error.
  • cmuenchowcmuenchow Registered User, Administrator, HES Staff
    edited July 2010
    It could be that the registry is pointing ESP in the wrong direction. Try these instructions:

    1. Select Windows Start\Run, type regedit and press Enter.

    2. Go to
    [HKEY_LOCAL_MACHINE\SOFTWARE\Flying Pig Systems\Wholehog III ESP] for XP-32bit,
    or [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Flying Pig Systems\Wholehog III ESP] for Vista-64bit

    3. Doubleclick on "Location".

    4. Add a single slash in the end of line, for example: "C:\Program Files\Flying Pig Systems\Wholehog III Connectivity\".
    Press Enter.

    5. Close Regedit and open ESP.
  • quinnquinn Registered User
    edited July 2010
    spcentral;48732 said:
    I am using ESP Vision. Here is a screenshot of the error.
    the fix.

    on a 64-bit machine, the key needing correctly assigned permissions will be:
    HKLM\SOFTWARE\Wow6432Node\Flying Pig Systems
  • quinnquinn Registered User
    edited July 2010
    c_muenchow;48738 said:
    It could be that the registry is pointing ESP in the wrong direction.

    dear chris:


    i'm quite curious to learn which functional / technical spec is satisfied by applying LockPermissions during a 3PC install.


    to persuade you to assist me in challenging that choice, i'll share with you a true piece of history - a real treasure, with the power to solve problems ten years into the future:

    Application Specification for Microsoft Windows 2000 for Desktop Applications


    published over a decade ago, Chapter 4 holds all the answers to avoiding every single one of today's LUA issues.

    especially notable is the prescribed testing as a standard user...



    please help.

    please let me know how i can help.

    because i want to help.





    inevitably, the rant, quoted in its entirety:
    quinn;42666 said:
    i've pointed this out a couple of times, but here's some more info, a quick fix, and a test for acceptance that you can perform yourself.


    UAC auto-elevation
    User ACCOUNT Control (and Windows NT, since inception) works slightly differently from what you've described.

    there's a very important distinction between a PRIVILEGE and a PERMISSION - a PRIVILEGE describes access to an operation (i.e. a set of functions) and a PERMISSION describes access to a resource such as a file or registry key.


    the RegOpenKey() function is what one calls to act upon an interest in a registry key or its value.

    considering that standard users have unlimited access to their own HKCU registry hive, it follows that RegOpenKey() does not assert that a standard user have any elevated PRIVILEGEs assigned to their tokens.


    in other words, standard users are allowed to call the RegOpenKey() function.


    however, if a standard user asks RegOpenKey() to operate on a resource under HKLM, that resource will likely have a permission set applied that allows a standard user "Read Only".

    so if a standard user uses RegOpenKey() to open a "Read Only" resource for Writing, RegOpenKey() will correctly return "Access Denied".


    this is where the distinction betweeen PRIVILEGE and PERMISSION becomes important -

    UAC will not auto-elevate a 3PC process because: a standard user token holds all PRIVILEGEs necessary to call every function that 3PC imports from the Win32 API's; even if a function returns "Access Denied", that function has successfully been called, run to completion, and returned a value to its caller.


    Again, the auto-elevation aspect of UAC is intended to solve problems with PRIVILEGEs, not PERMISSIONs.

    for examples of PRIVILEGEs that will cause UAC to auto-elevate, see Privilege Constants (Windows)
    UAC Virtualization
    in addition to auto-elevating when PRIVILEGE requirements are detected, UAC provides facilities for dealing with an application's PERMISSION requirements.

    specifically, when a standard user tries to write to "Program Files" or HKLM, they should get "Access Denied".

    instead, UAC intervenes by redirecting those write operations to targets located in an area that the standard user *does* have permission to modify.


    in the case of a standard user attempting to create a file named "~lock" in "C:\Program Files\Flying Pig Sytems\Hog3PC", the file "~lock" is instead written to "C:\Users\Standard User\AppData\Local\VirtualStore\Program Files\Flying Pig Systems\Hog3PC"

    similarly for "HKLM\SOFTWARE\Flying Pig Systems" registry entries, there are standard-user-accessible keys under "HKEY_USERS\{SID}_Classes\VirtualStore\MACHINE\SOFTWARE\Flying Pig Systems"


    both operations, reading to and writing from these redirected resources, are handled by UAC Virtualization, and are completely transparent to the 3PC applications.


    So why is this causing problems with Hog3PC?

    well, it's because of some permissions set on the registry by the 3PC installer.

    specifically, the MSI LockPermissions table applies permissions to the ProductVersion, EnlargeToolbarButtons, and InstUpgrade entries.

    the set of permissions applied "forget" to allow standard users "Read" access.

    and, unfortunately, since the actual "Software\Flying Pig Systems" keys are non-existant until these values are created with their errant permissions, the actual "Software\Flying Pig Systems" key assumes the permissions used to create ProductVersion, etc.

    so, when 3PC is run as a standard user, it: does not have permission to read its own registry values, throws an fps::exception when trying to read its own registry values, and is unable benefit from UAC Virtualization when writing to these values.
    please find attached a set of MSI transforms that cause these registry keys/values to be created with the default permissions inherited by HKLM\SOFTWARE.









    to use them:[LIST=1]
    [*]provision a "greenfield" Windows 7 or Windows Vista machine, which has never had 3PC installed to it (because other registry values are created at runtime, the 3PC installer does not know to remove them during an UNINSTALL, and the errant permissions will still be in place)
    [*]place Hog3PC-Win32-golden_3-1-0-2672.msi and 2672-LUA.mst into a single folder
    [*]open a command prompt
    [*]cd to this folder
    [*]msiexec/i Hog3PC-Win32-golden_3-1-0-2672.msi TRANSFORMS=2672-LUA.mst
    [*]drive the install sequence as normal
    [*]launch launcher as a standard user
    [/LIST]there are a few other areas that need their permission sets refined, such as the Services - these need to be modified to allow standard users to control starting and stopping.


    but overall, the adjustment of a few permissions is very, very little work required to achieve compatibility with a standard user context.


    Chris - i'd very much appreciate it if you took this to Robbie's attention.
  • spcentralspcentral Registered User, Hog Beta
    edited July 2010
    Thanks for the help. Got everything running here now.
  • srautanesrautane Registered User, Hog Beta
    edited July 2010
    It would be also nice to get rid of the 998 error in connectivity driver and Wyg crashing...

    I find it a bit strange that I have to disable UAC, firewall, antivir to get the H3PC working.
Sign In or Register to comment.