[StartIsBack+ 1.7.5]

On 02/04/2016 at 1:01 AM, Tihiy said:

I'm afraid this issue is not easily resolveable as without functionality restricted by SpyShelter SIB cannot function. I don't understand why it doesn't work only in Firewall version and only in Better compatibility mode.

Try persuading author into contacting me to discuss whitelisting or my efforts to avoid being broken by SpyShelter.

On 02/04/2016 at 1:37 AM, deipotent said:

Thanks for reply @Tihiy. I have relayed your message and asked him to contact you. You could also try to contact him (through SS website). Let me know if there's anything I can do or test.

Not sure if the author of SpyShelter ever contacted you @Tihiy , but I received another reply saying that they had also managed to reproduce the problem in Better protection mode as well. They also said the issue points to StartIsBack injected code and that it calls at undefined address.

[StartIsBack+ 1.7.5]

Thanks for reply @Tihiy. I have relayed your message and asked him to contact you. You could also try to contact him (through SS website). Let me know if there's anything I can do or test.

[StartIsBack+ 1.7.5]

There is a conflict between StartIsBack+ 1.7.5 and SpyShelter 10.7.3 x64 (and some of the few previous versions) - Specifically the Hooks Guard feature when in Better Compatibility mode. After Windows login, you just end up with a black screen and the Desktop never loads, although the mouse cursor still moves and Ctrl+Alt+Delete brings up login options.

I contacted the author of SpyShelter and they said it's caused because StartIsBack+ does not check the API funcs return codes. They did not say exactly which one, but I assume SIB+ does not take it into account and continues to try to do something which it shouldn't.

To reproduce, install SIB+ 1.7.5 on Win 8.1.1 x64, then install SpyShelter Firewall 10.7.3 x64 (http://www.spyshelter.com) with Keyboard encryption driver (default install options should sufice) and reboot. Login to Windows and open SpyShelter GUI, then switch to Keystroke Encryption tab > Advanced tab and change Hooks Guard to Better compatibility mode. Reboot Windows and when logging in you should get black screen.

I believe the same issue also occurs with Win 10 x64 and SIB++.

Any chance of looking into this and getting a fix ?

[StartIsBack+ 1.7.5]

So you observe ActivationData gets deleted in your case? That's strange. It is deleted only in the case server reports invalid license key or other error.

Can you try to backup ActivationData and restore it as ActivationData1 on different hardware?

Hi @Tihiy,

 

I've come back to this issue with SIB+1.7.5 and have some new observations:

 

- If ActivationData exists but hardware changes, it does create ActivationData1, which is what you were saying should happen.

- However, SIB+ only seems to check ActivationData and not ActivationData1, since it stays un-activated. If I activate again, it just creates AcivationData2, but still stays un-activated.

- If there is no Internet connection and you activate, SIB+ wipes out all ActivationData and LicenseHash registry values. This should not happen IMO.

[StartIsBack+ 1.7.5]

 

SIB does that. For example, you can try to corrupt ActivationData value and then activate again. ActivationData1 will be created and used.

Are you using per-user or per-machine install?

I just manually corrupted the ActivationData and after re-activation, it did indeed create ActivationData1. As it doesn't do this if I activate in BootCamp native and then reboot into Fusion VM BootCamp, I'm wondering if SIB+ takes a different path the first time it detects different hardware, since the ActivationData key is definitely present when it overwrites it with new data.

Would you be able to create a debug build, whereby SIB+ logs to a text file the registry path(s)/key(s) it checks for Key and ActivationData (include the actual data in the log). This will allow us to make sure SIB+ is reading the correct data.

[StartIsBack+ 1.7.5]

Ah, so you work for Parallel's on Desktop ?

 

When I last tried PD a few versions ago with a Win 7 x64 BootCamp install, I found that when the VM was booting, the bootup orb was displayed briefly but then disappeared for the rest of the boot. With Fusion it always displays as normal during the boot process.

 

 

Re. my SIB+ issue, just to be clear that when running the VM, it hasn't made a copy of the BC partition, it running of the actual BC partition.

[StartIsBack+ 1.7.5]

Still haven't heard from you on this. Any chance of getting support for this in SIB+ 1.7 ?

I was unable to reproduce your issue yet, sorry.

 

Have you tried it on a Mac BootCamp installation of Windows, while using VMware Fusion to run off the BootCamp partition as a VM ?

[StartIsBack+ 1.7.5]

 

Per machine, as I want settings to be same between all logins.When I checked those registry keys before and after activation, the LicenseHash value obviously stayed the same, but the ActivationData changed (ie. old data was overwritten with new data, rather than a ActivationData1 being created with the new data).This is on Win 8.1.1 x64 with latest SIB+ 1.6.2

Any update on this Tihiy ?

You mentioned it should already do this, but that's not what I'm seeing

 

Still haven't heard from you on this. Any chance of getting support for this in SIB+ 1.7 ?

[StartIsBack+ 1.7.5]

Per machine, as I want settings to be same between all logins.When I checked those registry keys before and after activation, the LicenseHash value obviously stayed the same, but the ActivationData changed (ie. old data was overwritten with new data, rather than a ActivationData1 being created with the new data).This is on Win 8.1.1 x64 with latest SIB+ 1.6.2

Any update on this Tihiy ?

You mentioned it should already do this, but that's not what I'm seeing

[StartIsBack+ 1.7.5]

I would rather send the dump to Tihiy direct via e-mail.

What e-mail should I send it to ?

[StartIsBack+ 1.7.5]

One other thing - I have been getting crashes in explorer.exe, module twinui.appcore.dll, but haven't found the cause yet as it's unpredictable. It seems to occur just after logging in and explorer.exe automatically restarts itself and doesn't seem to crash 2nd time around.

Have you had any other reports of explorer.exe crashing in module twinui.appcore.dll, and could it be caused by SIB+ ?

I have a crash dump I can send, but the analysis just points to twinui.appcore.dll as the culprit.

[StartIsBack+ 1.7.5]

Per machine, as I want settings to be same between all logins.

When I checked those registry keys before and after activation, the LicenseHash value obviously stayed the same, but the ActivationData changed (ie. old data was overwritten with new data, rather than a ActivationData1 being created with the new data).

This is on Win 8.1.1 x64 with latest SIB+ 1.6.2

[StartIsBack+ 1.7.5]

Just to clarify - I used same key, but every time I switch between BootCamp native and the Fusion BootCamp VM (which runs off of native partition).

 

So the licence data from one activation will not overwrite the licence data from the other activation (ie. two lots of licence data can/will exist at the same time on the same partition) ?

 

I will try what you suggest and report back.

 

I tried what you suggested but I have the same problem. I traced where SIB+ was storing the licence and activation data and see that it saves it in the registry here:

 

HKEY_LOCAL_MACHINE\SOFTWARE\StartIsBack\License\LicenseHash

HKEY_LOCAL_MACHINE\SOFTWARE\StartIsBack\License\ActivationData

 

The problem is that it only ever stores one lot of activation data, so every time I switch between native BootCamp Windows and Fusion VM Windows it just overwrites the previous activation data.

 

The solution is to store more than one lot of activation data (ie. ActivationData1, ActivationData2, ActivationData3...), and try each one when seeing if it is activated.

 

Any chance you can add this into SIB+, as it makes using SIB+ on a Mac (when switching between native BootCamp Windows and Fusion VM Windows) a pain given that it has to be re-activated every time I switch between the two ?

[StartIsBack+ 1.7.5]

Just to clarify - I used same key, but every time I switch between BootCamp native and the Fusion BootCamp VM (which runs off of native partition).

 

So the licence data from one activation will not overwrite the licence data from the other activation (ie. two lots of licence data can/will exist at the same time on the same partition) ?

 

I will try what you suggest and report back.

[StartIsBack+ 1.7.5]

I have a 5-PC licence and am having activation issues when trying to use SIB+ on a MacBook when switching between the native Windows installation (ie. BootCamp) and the VMware Fusion VM version (which runs off of the same Windows partition as the native version, rather than being a copy of the partition).

 

1) I boot to Windows native and activate SIB+, which works fine.

2) I then reboot into OS X, start the Fusion Windows VM and SIB+ asks to activate again, which is also fine.

3) If I reboot into Windows native, SIB+ asks to activate again, which is not fine.

 

The activation from step (2) seems to have wiped out the activation data from step (1) I use another app that also uses activation, but it gets around the above problem by storing multiple hardware ID's/signature's, activation code's and response's in a file, and when it performs the "Am_I_Activated" check, it compares the current hardware ID against all stored activation information to see if there is a match. If this hardward ID has already been activated, and is in the file, then the activation check passes, without requiring activation again.

 

Can you change the licencing/activation scheme of SIB+ slightly, so that multiple activations/ID's are stored in a licence/activation file, instead of just one (which seems to be the case at the moment)

[Weird behaviour with Windows installation on multi-partition disk]

If I install Windows onto a disk which has multiple partitions (eg. C:\ and D:\), and set the target as C:\, a few of the folders will be created on the D:\ partition. Windows will work perfectly well, but the D:\ will sometimes be used when installing new apps. For example, installing Visual Studio 2008 Express will result in a temporary folder being created on the D:\ partition.

However, if I only have a single partition when Windows is installed and then create a secondary partition afterwards, Windows does not use the second partition and temp folders are not created on the second partition during installations either.

I have checked the list of environment variables and they all point to the C:\ partition.

Why does this happen ?

Could it just be poorly coded installers that for whatever reason result in some files ending up on the secondary partition ?

[Newer nVidia drivers cannot be installed if they have been slipstreame]

I've had a look at the nVidia site and it looks like the control panel was updated from 162.18 to 163.71, so this might be the problem.

[Presets not always fully restored]

I've noticed that if I load a presets file at the beginning of an nLite session, not all the settings get changed. For example, all hotfixes, drivers and components were listed/shown correctly. However, on the Unattended section, all presets had been restored apart from my user account. When I loaded the presets again just for this section, the user name was added. Likewise, on the Options section, all general settings were correct apart from the temp folder. Again, loading the presets for this section only corrected the problem.

So, it would appear there is a problem (on my system, at least) where all preset settings are not loaded if a presets file is loaded at the beginning of the session.

[Newer nVidia drivers cannot be installed if they have been slipstreame]

I slipstreamed nVidia 162.18 drivers onto XP Pro x64 SP2, and then used the ISO to install Windows. However, I then tried to update the nVidia drivers to 163.75 from within Windows, by running the nVidia installer. It all seemed to go OK, but after the reboot I was informed the control panel applet version did not match (ie. the driver version).

I could carry on using Windows OK, but could not use the nVidia control panel applets due to version mis-match.

[Disable Password expiration does not work XP Pro x64]

I have tried leaving this option enabled and having Days set to zero, and also tried disabling the option, but it doesn't work. I check by doing the following:

1) running "control userpasswords2"

2) On User Accounts dialog, click Advanced tab, followed by Advanced button under "Advanced user management"

3) On Local Users and Groups dialog, click Users in the left-hand tree, followed by double-clicking the user in the right-hand list.

The option "Password never expires" on the General tab is un-checked.

nLite version 1.4.0.5

Can anyone confirm ?

BTW, should problems be reported in separate topics, or under the main sticky ?

[nLite 1.4(.1) - - ->]

The tweak to add a context menu item for "Open command prompt at this location", results in the following text being displayed for the menu item

"@SystemRoot\system32\shell32.dll,-22022"

Can anyone confirm this ?

[nLite 1.4(.1) - - ->]

I'm also finding that a tweaked version of XP Pro x64 will not install in VMWare Workstation (at the beginning of installation, it says "Windows could not detect any hard disks"). The exact same version (ie. SP2 integrated, RAID, audio, nvidia driver integrated), but without the tweaks has no problems. I am in the process of going through the tweaks to see which one is causing the problem.

The problem was caused by removing the RAID/SCSI component, since VMWare defaults to creating virtual SCSI disks instead of IDE.

EDIT: Further to this, I noticed that I couldn't install VMWare tools once XP had been installed. This was because I had disabled Autorun. The VMWare Tools install feature works by mounting an ISO containing the tools. With autoruns enabled the setup starts automatically, but with autoruns disabled the ISO gets mounted but setup doesn't get run. Simply browse to the newly mounted ISO and start it manually.

[nLite 1.4(.1) - - ->]

The tweak to add a context menu item for "Open command prompt at this location", results in the following text being displayed for the menu item

"@SystemRoot\system32\shell32.dll,-22022"

I'm also finding that a tweaked version of XP Pro x64 will not install in VMWare Workstation (at the beginning of installation, it says "Windows could not detect any hard disks"). The exact same version (ie. SP2 integrated, RAID, audio, nvidia driver integrated), but without the tweaks has no problems. I am in the process of going through the tweaks to see which one is causing the problem.

[nLite 1.4 beta - Back to the roots]

Couple of bugs I've noticed with 1.4 beta (nLite'ing XP Pro x64):

1) System failure: Disable Auto restart - This tweak doesn't work as it is enabled when you boot into Windows.

2) XP Theme Silver - This tweak doesn't work as it uses the Blue default theme when you boot into Windows.

3) Custom Program Files folder - I set this to "C:\Program Files" and when I checked the folder structure in Windows, there were four program folders:

- "Program Files"

- "Program Files (x86)"

- "Program Files (x86)(x86)"

- "Program Files(x86)"

4) LAN Connection setup - I have it set to Custom and configured both connections to use a custom IP address and Mask, but in Windows neither have been set up (ie. they both use defaults). BTW, I also integrate my LAN drivers.

It wold be nice if you could:

a) also tweak the "System failure: Send an administrative alert" option to disable it.

b ) Specify which user name the logon prompt displays on first boot (currently, it always displays "Administrator")

[nLite as learning tool ?]

In trying to see if nLite could be started with a command-line parameter to stop the optimization, I found that it causes an error (eg. "nlite.exe /?") in either nLite or .NET.