Windows 7 Service Pack 1 Original Iso

0 views

Skip to first unread message

Boone Southern

unread,

Jun 30, 2024, 8:27:18 AM6/30/24

to erderloanea

Background:
If I install old installation package (created in 1998) the service starts without any problem.This package was created using InstallShield and project code is not available. It is using local deployment and all the dependent DLLs are in bin directory. It used custom installservice.exe (code for this also not available) to install lp30.exe as windows service.

windows 7 service pack 1 original iso

Descargar Zip ☑ https://www.google.com/url?hl=en&q=https://shurll.com/2yPd0B&source=gmail&ust=1719836835594000&usg=AOvVaw3nWz9G1X7XCZaOwdb8hyog

Analysis:
installservice.exe could not start the lp30.exe as service. It is failing at the library call to PS2FaxW.dll Function. This is a third party DLL dated back in 1998, source code of which is not available.

Question:
I am using the same "installservice.exe" and same application (lp30.exe) for starting the service. But the behaviour is not as it was with old package. What other configurations, I might be missing in this scenario?

The current directory for a service is, by default, the system32 folder as written in Current directory for Windows service is not what you expect. Also see this StackOverflow question What directory does a Windows Service run in?.

Essentially your service is trying to load the DLLs from system32, not the application directory. You could try putting the LincPag2.dll into system32 and see if that temporarily solves the problem. I don't think putting the DLLs in system32 is the best long term solution, but it could be a useful debugging step.

1) Open a CMD window with elevated privileges. [Windows Key-X to bring up a menu with the option; select "Command Prompt (Admin)".]
2) Use the parenthetical name from the list in Services [for example, I used "sc delete gupdate" when, in Services, it read "Google Update (gupdate)"]

The command sc query type= service (note, it's very particular with formatting, the space before "service" is necessary) will output a list of Windows services installed, complete with their qualified name to be used with sc delete command.

HOWEVER, the query command did not work the first time, because the tomcat service was not running. It seems to only list services that are running. I had to start the service and run the query command again.

If the original Service .InstallLog and .InstallState files are still in the folder, you can try reinstalling the executable to replace the files, then use InstallUtil /u, then uninstall the program. It's a bit convoluted, but worked in a particular instance for me.

Lots of great answers and this really helped me, but there was one thing that was missing. There's a mention of finding the service through cmd with sc query type= service but the problem is that the service I was looking for wasn't running and this command only shows running services (which may be a new feature that didn't exist at the time of the OP answer).

We discovered that even if you run sc_delete, there can be an entry remaining in the registry for your service, so that reinstalling the service results in a corrupted set of registry entries (they don't match). What we did was to regedit and remove this leftover entry by hand.

I recently helped a site investigate a problem that appeared after they upgraded their Windows instance of Cach from 2015.1 to 2017.1. A terminal session launched from the server's desktop cube was unable to run OS-level commands using the $ZF(-1) function. For instance, using the no-op command "REM" as follows:

It turned out that their original 2015.1 Cach service was running under a specific Windows account (as opposed to LocalSystem), which is commonly done in order to allow background processes to access UNC shares. Indeed, when installing with Normal or Locked Down security you are prompted for the credentials of a Windows account to run the service as.

Normally the only reliable way is to modify the service to report or log the parameters. As this is likely not possible you can temporarily replace the service executable with one which does report the parameters. You can grab a very simple executable intended specifically for this task from here. Once you have gathered the information you require replace the executable with the original.

From within services.msc you can open the properties of a service and look for Path to executable: which has the entire launch string underneath, including parameters the system uses when firing it up

I've had a look in the Windows Event Viewer, but, to be honest, I'm not sure what I'm looking for, and there is a lot to work through. Nothing has jumped out at me, but I suspect it's just that I don't know what I'm looking for.

If it is a generic user name, such as "administrator", then it's time to stop using generic account, and you'll have to correlate the date / time of the event with other info you could get from other log (like: Microsoft-Windows-TerminalServices-LocalSessionManager/Operational which can give you the source IP of a remote desktop session)

In Event Viewer, look in the "Windows Logs"->"System" event log, and filter for Source "Service Control Manager" and Event ID 7040. Find the event saying "The start type of the service was changed from original start type to disabled" for the service you're interested in. When you find that, the "User" listed in the details below is the user that has made that change.

Can anyone elaborate on why you'd have to reinstall? Does the account get embedded in the configs somewhere in addition to the windows service? I have an install that was done months ago using the local system account, and I'd like to change it to use a domain account. Assigning all the needed permissions and rights shouldn't be a problem.

You shouldn't have any issues changing the account that the service is running as. As long as that user has the right to logon as a service, which windows will take care of when you assign the account to the service, you won't have any issues. I installed my system and then switched the service to run using a domain account when WMI did not work and have not had any issues at all. Also, I'm using the built-in Splunk security and it has not thrown any errors when changing the configuration, which would happen if the service account did not have the ability to write to files in the Splunk installation directory.

You don't really, but you'd have to change ownership possibly permissions all of the installed files. There is a mix of read/read-write/read only by owner, etc. permissions on various installed files, and others on files that are generated on first-time run, and others as configuration and initial directories for data. So it might be easier to reinstall. Now, you actually could just change the ownership on all of them. Though really, a default installation has everything under c:\Programs\Splunk, so you could just cascade the ownership change down from there and it should be fine.

I read about the difference. If you run Resilio Sync as a Windows Service, it just runs automatically. You also can only make adjustments via the web browser instead of a dedicated GUI. But, does that matter? I would think that running it via Windows Service would be more efficient. Further, since the web browser UI is the same as the GUI in terms of features, is there a reason not to run Resilio Sync as a Windows Service?

I've run Sync as a service since the feature was introduced. IMO the biggest advantage of running as a service are that Sync runs once the machine is on, regardless of whether you're logged on. If, like me, you have a bunch of machines you manage, then that means you don't have to manually log on to start Sync. Once the machine boots, Sync is running.

I don't have any recent comparison of this but sync typically uses 200 to 300 MB RAM on my machines anyway. Since the minimum installed RAM on my x86-64 machines is 16 GB, I don't really worry about that. Most of the CPU usage is due to hashing, which is independent of any UI.

The only situation in which you would not want to run Resilio Sync as a service that I can think of is when you have multiple Resilio Sync users on the same machine. Services are single instance, which means that they're tied to a single Resilio Sync identity/account. Obviously that won't work very well for separate Sync accounts.

I personally never start RSL as service on my Windows systems, I don't even have it automatically start when I log in. I only start it when I need to sync files, and exit it once the synchronization finishes.

On the other hand, I am not sure if the pop-up menu works correctly when running RSL as service on Windows (I am talking about the RSL pop-up menu when you right click on files, such as "Sync to this device / Remove from this device / Remove from all devices", etc.)