Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I created one service in C# and created installer for that.Installer is working fine and service is installed properly on server. But here is one problem. When server restarts the program connected to service automatically getting deleted from C:\ProgrameFiles location, but service is still there and when restarting this service. I am getting prompt like "windows can not find specified program path". Can somebody help me what I am missing here or what is potential cause for this problem?
I know the the scope of this question is too broad to answer but still I want some hints or any solution to resolve this issue. I tried to searching many forums but unfortuanatly no luck. please consider while vote to closing this question. I can edit more to clarify this scenario.
Thanks.
What kind of server is this? Terminal server?
UPDATE: It isn't a virtual machine is it? If so, are the disks set fully persistent? See 9.
If you run repair on the MSI in question, does the file come back?
What happens if you check the file directly with your malware scanner?
If you shut down the service manually, is the file still there? (just to be sure). Try repeatedly stopping and starting the service a few times.
Did you verify that the service runs from where you expect after installation? (have to ask)
Do you install per-machine or per-user?
Debugging
Check the event viewer and the MSI log files:
MSI Logging: Installsite: MSI log "how-to" and / or More MSI logging information.
Event Viewer: Hold down Windows Key, tap R, type eventvwr.msc and press Enter. Go to Windows Logs => Applications. Look for MsiInstaller events. Check the other logs too (Security, System, Configuration).
Deployment Mnemonic: And a "deployment mnemonic" (yellow section) - some heuristics to think about deployment problems.
Some Ideas
Loose Cannon: While we wait for feedback from you, let's fire off a list of suggestions shooting from the hip. Some of these are bad or
eliminated as causes, let's just list all to remember the bad ones
too:
1) Quarantined malware? (real or false positive, doesn't matter which). The file gets quarantined on every reboot? Upload file(s) to virustotal.com to check binaries that are missing. Do an administrative installation if you need to get hold of the files.
2) Upgrade Problem? (not the cause in this case, but MSI major upgrade can cause this kind of problem - for example when you attempt to downgrade a file to a lower version).
3) System policies? Not really familiar with what policies that could delete files - if any at all. Just mentioning that a lot of policies can affect Windows in general. Check the event logs. Some registry keys are periodically overwritten for example with defined AD settings.
4) Cleanup Scripts? Anything is possible here, but it would be strange to delete a pinpointed executable? Check what runs on boot? Autoruns. Run that tool and have a look at auto-starting binaries - there are a lot on most systems.
5) System Restore? Not relevant here as far as I can tell, but system restore can do VERY strange things such as delete single files from somewhere unexpected out of the blue. Yes, I have seen it (not a fanboyism - I was there - in the fires of mount Doom - it really happened).
6) Recovery hardware? Some computers have hardware devices that restore the system to earlier states on reboot with various options to allow some persistence here and there. No idea how prevailing these are now, but I expect their use for quick malware recovery and stuff like that. Talk to your system administrators?
7) Permissions? Does the package apply ACL permissions to the folder in question? It shouldn't cause this problem, but maybe check it. The service should never be able to start at all if permissioning is wrong.
8) Disk Corruption? An issue that one must always check for.
9) Virtual Machine? One issue that came to mind is whether this server is running as a virtual machine and if so whether the disk setup is one of full persistence? Not sure what is technically possible here at the current day and time.
10) Hidden Icons? One more issue - added in a hurry - some icons can be hidden in the Windows start menu from Windows 8 upwards (I believe, details fuzzy). I suppose this can yield the impression that a product has been uninstalled, when it is just hidden. Almost certainly not relevant for your situation.
Questions
PendingFileRenameOperations: After installation, are there entries in PendingFileRenameOperations? Check BEFORE installation as well.
Are there pending operations waiting for a reboot?
Location: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager
Rollback: Even more obscure, is rollback disabled for Windows Installer? I can't see how that would cause this problem, but it is possible to do and what it triggers and makes possible I am not sure of.
Bitness Confusion: It is possible that people just think that files are missing, because they are looking in the wrong folder (x86 instead of x64 or vice versa). Not relevant here (then the service would start - unless there is something else wrong), but listed to remember it for other, similar cases.
"Out There": This is C:\Program Files\ right? Not C:\ProgramData\? Are there any mounted disks on the NTFS partition? Any symbolic links? Roaming profiles? Do you install per-machine or per-user?
Related
Update: It turned out that there was something with installing Delphi 10.4 CE that broke my app (thanks, DelphiCoder!); specifically, it was something in the Windows Registry that was broken. After using ProcessMonitor to ensure no Delphi 10.4 (aka 21.0) was being invoked, I ended up cleaning out the registry of all 10.4 references, rebuilding completely (not clear if this was needed or not), and lo and behold, it works again! I'm adding this update in case someone in a similar situation finds this question - remember to back up your registry first and be careful!
Original Post: I created several DLLs with Matlab Compiler 10 years ago, with C wrappers, to make them available with Delphi. Once I got them working, they always worked - until today! The code in the C wrapper initialization function in question is in the code box below; the "Could not initialize library" is printed to the console when I run my Delphi app.
mclmcrInitialize();
if (!mclInitializeApplication(NULL, 0)) {
fprintf(stderr, "Could not initialize application\n");
}
if (!libMyDllInitialize()) {
fprintf(stderr, "Could not initialize library\n");
}
The problem is that this has never happened before, over all the probably 10 years since we first wrote these! My machine has the correct version of the 32-bit 2021a MCR installed, as it has for several years; I've installed this on numerous machines from Windows XP up to Windows 10, The DLLs were last built 5 - 7 years ago; anyway, I don't have access to the Matlab compiler anymore. The only thing that has changed is my app, but not anywhere near where this DLL initialization code is called; also, when the problem first happened, my app was working, then didn't -without any changes. Finally, I went back a few days and rebuilt my app, and it still fails.
So I am really stuck, and need some advanced help in debugging DLL startup issues on Windows. I tried looking in the Windows Event Logger, but nothing appears to show up there. Logs to check? A setting in the Registry that somehow got hosed? Wrong phase of the moon? How does one debug loading/initializing a formerly working DLL when forced to treat it as a black box? Help!
How does one debug loading/initializing a formerly working DLL [...]?
I think there is no definitive answer to your question.
This is how we have gone about debugging the loading/initializing of DLLs and applications and may help you:
We regularly work with systems where we have no source code for the DLLs (and often we don't have any source code for the applications either). We experience DLL conflicts quite regularly. When testing why applications don't start as expected we have found the use of Sysinternal's Process Monitor by Mark Russinovich invaluable.
This will show you system level activity. You can filter for your process and then you will see all file, registry, thread and network activity (although thread and network are quite limited). If the DLL has dependencies then the system tries to find those and so you will be able to discover all dependent DLLs and COM interfaces (by seeing the registry lookups for that interface) that it's looking for. Process Monitor will show if the resource is not found or if access is denied.
Slightly more difficult to discover is if one of the dependencies exists but the export table has changed (so the functions have different signatures or export ordinals). There are ways to check that (by looking at the export and import tables) but generally (if you have access to a working environment) it's enough to check the filesize, timestamp (and the VERSIONINFO resource if there is one) between DLLs.
Can anyone suggest me the steps to apply patch (patch upgrade) on IBM Informix database. Please suggest the best practices available. If possible share me the URL or any documents.
It's a big topic. A good deal depends on how the server is currently set up — there are setups that make it hard and others that make it easier. Another major factor is your level of risk averseness. You need to make an assessment of the amount of down-time you can afford. Also, how often have you practiced recovery from backups — it probably won't be necessary, but you need to cover your bases.
I am assuming you're using Informix Dynamic Server, not Informix Standard Engine (SE). Upgrading SE is much, much simpler.
Preparation
Before you install, make sure you have a good, recent, level 0 archive of your system.
Also, make sure you know where your software is installed, and which disks and files it uses.
Route 1: Simple, but potentially risky
Make sure you have a backup copy of $INFORMIXDIR.
Take down the servers that are currently running using this $INFORMIXDIR.
Install the new version of the software over the existing software.
Restart the server
Why is this risky? At issue is what happens if anything goes wrong, and also the length of time the server(s) is (are) down. If you bring up the server and decide something is wrong and you wish to go back to the old version, you have to take servers down, reinstall the old software (copy off the backup?), and then bring the (old version of the) server back up. This takes time. This isn't often a problem, but it has happened on occasion over the last couple of decades.
Route 2: Parallel install
This is the way I do it, but I ensure that my system is set up so that this is easy to do. In particular, the file names used to identify the chunks used by the server are symlinks to the actual storage. This makes it easier to move or replace storage when necessary — you change the symlink instead of having to modify the server configuration.
Create a new directory (e.g. /opt/informix.new) and install the new version of the software in it.
Copy the configuration files from the current $INFORMIXDIR (e.g. /opt/informix) into the new one.
Ensure any other files or directories under the old $INFORMIXDIR that are needed for the new one are copied across or recreated empty.
Review the parallel setup; as best you can, make sure that when you're ready to switch, everything will work.
Take the old server down.
Move the old $INFORMIXDIR to a new name (i.e. mv /opt/informix /opt/informix.old).
Move the new $INFORMIXDIR to the working name (i.e. mv /opt/informix.new /opt/informix).
Restart the server
Why is this less risky? The primary advantage is that the old software is still on the machine and switching back to the old version is therefore simply a question of undoing the original pair of move commands. Another major advantage is that the down-time for the system is limited to the time taken to stop, switch directories, and restart the system.
What are the potential downsides? If you weren't careful enough about copying the necessary files from the old to the new system, you can find yourself missing something critical.
Note that if your chunks are not symlinks, and especially if they are cooked files stored under the old $INFORMIXDIR, you can run into problems. These are not insuperable; you just have more work to do than simply moving directories. Do not (repeat not) move or copy chunks while the server is running. They will not (necessarily) be consistent.
Variations? I usually needed multiple versions of Informix around, so I'd use sets of directories like /work3/informix/ids-12.10.FC1 and /work3/informix/ids-11.70.FC4 as the real directories. I'd then use a standard symlink name as $INFORMIXDIR, such as /opt/informix which would link to the current version-specific INFORMIXDIR under /work3/informix in this example. (Actually, there were some extra levels of complexity in my setups, but my requirements as an Informix developer were different from those of most customers.). But the key point is that instead of moving directories, I switched a symlink — rm /opt/informix; ln -s /work4/informix/ids-12.10.FC3 /opt/informix to use 12.10.FC3 instead of 12.10.FC1, for example.
Post-installation
Run a new level 0 archive.
General observations
Informix upgrades are usually seamless and smooth. If there is conversion work to do on the upgrade, the server does it automatically when the new version is brought up.
Be aware of the mechanisms for reverting to an older version of the server if that is found to be necessary.
I've done presentations and/or papers on this in years past at IIUG conferences. Check out the IIUG web site, and the IBM Informix documentation.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
The community reviewed whether to reopen this question 10 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I've been thinking of rolling my own code for enabling my Delphi application to update seamlessly as I'll be going for "release often, release early" mentality furthermore. There are various Delphi solutions (both freeware and paid) out there and I'd like to ask if you've been using any of them or simply went on with your own solutions in this area. Any comments on the auto-update topic are welcome.
What ever scheme you use, it may be handy to know that you can actually rename a running .exe file. So rename file, copy in new file works nice. And the next time someone launch the program they will launch a the new version. This is ofcourse very handy in enviroment where many users run the same .exe file, like in citrix/terminal server/network share cases.
Years ago I wrote a simple tool which is started instead of the real program, checks for updates, loads and installs them (if any are available), and finally starts the real application.
There are however problems with that approach if your program works in a properly administered environment, where users normally don't have write access to the program directories. You can no longer simply update your own program in such environments. That's why a lot of programs these days come with their own updater tool, which can be installed to run with elevated permissions, so that program updates can be applied even though only standard users do ever log on to the system.
You have to decide whether your target audience can be assumed to run on power user or administrator accounts, or whether you will have to deal with above-mentioned problems. With Vista things got considerably harder already.
With all these problems (net access over proxies, missing write permissions for installation directories, the need to update files that the updater itself is using - just to name a few) I wouldn't try again to code this on my own. Much better to check if any one of the available solutions does all you need it to.
I use the Synapse routines GetHTTP to return a specific resource, and if found then check against the local system to see if an update is required. If so then the resource tells me what page to go to launch and I throw the URL into shell execute so the users
preferred browser is displayed.
Most of the time the download is a setup program created by InnoSetup which updates the users system and database to the latest version. When a new "paid" upgrade is needed, I then send the user to a "purchase upgrade" form. My web resources are ASP pages, so I can redirect to a different resource based on the customers version number.
For the main application (our application has a server piece, and a client piece) I have a loader which will check the server to see if the version of the client file on the server is different than the version on the client...if so, it prompts the user if the user wants to update/revert. We chose to prompt the user as sometimes an accidental bug might make it into the system and the user has to downgrade/upgrade only specific machines to help troubleshoot. I maintain a database record with the minimum version required which is updated via the database patch, so if a version must be retired then the record is updated accordingly.
I created my own solution too based on Indy for downloading and http://sourceforge.net/projects/makeupdate/ for file patching.
Before that I have used and tried several commercial tools, but no one was doing exactly what I needed.
I use TmxWebUpdate. It's free, simple and gives you good control over the process. I actually own TMS Component Pack with TWebUpdate but never really found a good reason to switch.
Edit: Link updated
We rolled our own as well. Its really not too difficult.
Our process goes something like:
When the main app is launched, it checks (using funcs from the synapse library) if there's an update available (assuming its configured to check, of course).
If so, it notifies the user and askes if they want to update.
If they do, it launches an updater .exe, and closes the main app.
The updater exe downloads the new files based on the contents of a text file it retrieves, keepiing the files in memory.
When the updater is done downloading everything correctly, it then saves the downloaded files to disk, backing up any files it replaces. This way if the download gets interupted, you dont end up with half the files installed.
Finally, it launches the main app again, and closes itself.
The trick w/ Vista is that you need to have an entry in the updater program's manifest to force it to run with administrator rights.
Normally we use the third party tool. But in some situations it was not usable so I created an own solution, which was pretty standard:
Get xml (or any other format) with update info.
If newer files are published, download and install them.
I use TWebUpdate . It works ok and has a ton of interesting options, but documentation isn't so great and I did bump into a few problems - which is why I download a full installer, instead of just the files...
I will be keeping an eye on this question, btw...
We use our own solution which follows these steps:
Application connects to http resource and downloads info file (ini text file) to memory, checks version number of newest release.
If newer version available, app downloads compressed binary package to exe location.
When download is finished, user is asked to restart application.
Upon start, application checks for presence of update package
App extracts package contents (usually a new app exe, but additional resources possible as well, e.g. updated language files etc.) - for each file it renames the current/old file to a temp name first, then extracts the new file. If the process fails at any point, the temp files are restored.
When finished, app executes new exe and closes itself.
No additional updater needed, the app exe can handle it all by itself.
For the compressed package we use our own update builder.
The package contains an index of files with a file hash, destination folder (relative path to main exe) and the compressed files.
During update we compare the stored hash with the extracted file to detect corupted files.
With Vista I see two solutions to enable Standard User Accounts to actually update the applications files:
Configure your setup to change permissions of the programs installation directory. This way files in "C:\Program Files (x86)\Your Company\You App" can be modified on Accounts with limited rights.
Example code for InnoSetup would be:
[Dirs]
Name: "{app}"; Permissions: users-modify
Install files that you plan to update to the ProgramData folder instead of the user defined directory and use this directory as an override folder. If files exist in ProgramData, use those, else check in install dir.
InnoSetup code:
[Files]
Source: "C:\Your Project\YourApp.exe"; DestDir: "{commonappdata}\Company Name\App Name\";
Same as "stg" and "GuyWithDogs", I'm using TWebUpdate from TMS. Although the documentation isn't so great, Its not so difficult to learnt.
With TWebUpdate, you have some options what the protocol you use, it could be done via HTTP, FTP or network access.
For communication layer, TWebUpdate uses WinInet. In some machines, the windows / IE URL cache can be frustating, so I've added a routine to clear the auto-update server address from cache first to ensure the information gathered from the server is up-to-date.
We have a Delphi program whose task is like a service program. It watches a particular folder for a certain period, and it works great on Windows XP and 2003, but on Windows 2008r2 64bit, when it wants to create an automatic folder, it will show this message:
The ... folder does not exist. The file may have been moved or deleted.
This message causes the program to halt, which is not good; it should not be interrupted.
What can I do about this?
P.S.: I really don't have any idea whether to post my problem in Stack Overflow or Server Fault, so I've guessed it should be here.
It's likely the VirtualStore, if you're trying to store beneath Program Files (either one). See my writeup:
http://www.clipboardextender.com/off-topic/vista-program-files-hide-and-seek
You've left out the ... folder name. While that's understandable, it wouldn't happen to have anything to do with program files (which on x64 will be split in 2 directories) would it?
Windows Server 2008 is able to use 'virtual' file pathes. That means: 'what you see is not what you get'. The Windows Explorer just shows you the 'display' name. Check the file path with cmd.exe, if the path you are trying to use does realy exist.
The reason is of cause the File Virtualization (see for example http://msdn.microsoft.com/en-us/library/bb756960.aspx and http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx).
Because we on stackoverflow.com and not on serverfault.com I want add to all other answers that you can use Wow64DisableWow64FsRedirection, Wow64RevertWow64FsRedirection and Wow64EnableWow64FsRedirection functions (see http://msdn.microsoft.com/en-us/library/aa365743.aspx) to control the File Virtualization in your program. An example of the usage of this functions in C# you can find here http://www.pinvoke.net/default.aspx/kernel32.wow64disablewow64fsredirection.
You'll need to tell us the exact path and how do you go about constructing it. It can be as simple as the app not using env variable expansion but assuming that user's folders are where they were before.
Path virtualization (there are 2 kids actually) that people mentioned will hit you only if your app is trying to mess with system folders.
More puzzling problem will hit you if you are not expanding env vars like APPDATA, LOCALAPPDATA etc. and not expecting that there's more of them on Win7 and 2k8. Not only that default paths of user's files changed but some of them can also be on network shares - for the same user. So if you were running based on expectation that all user's stuff will be at definite paths under say %USERPROFILE% you can get hit by several surprises. Also notice %ProgramData% .
Fastest way to find out - open cmd.exe, run set and if you see some paths that you are constructing in alternative ways, take notice that you need to start expanding env vars for them. Then open cmd.exe as a 32-bit app and check set again. You can also pick them up via Process Explorer from some running 32-bit or 64-bit app.
Switching your app to 64-bit build will resolve most of virtualization issues but not the env var expansion. Also if your app is touching system folders you need to request elevated run from the code or even better make the manifest and declare it there. Then OS will yell at user up front if his UAC is on and your app will avoid that 2nd virtualization. BTW, virtualization is controllable via group policies so it might be present on some boxes and missing on others.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
The community reviewed whether to reopen this question 10 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I've been thinking of rolling my own code for enabling my Delphi application to update seamlessly as I'll be going for "release often, release early" mentality furthermore. There are various Delphi solutions (both freeware and paid) out there and I'd like to ask if you've been using any of them or simply went on with your own solutions in this area. Any comments on the auto-update topic are welcome.
What ever scheme you use, it may be handy to know that you can actually rename a running .exe file. So rename file, copy in new file works nice. And the next time someone launch the program they will launch a the new version. This is ofcourse very handy in enviroment where many users run the same .exe file, like in citrix/terminal server/network share cases.
Years ago I wrote a simple tool which is started instead of the real program, checks for updates, loads and installs them (if any are available), and finally starts the real application.
There are however problems with that approach if your program works in a properly administered environment, where users normally don't have write access to the program directories. You can no longer simply update your own program in such environments. That's why a lot of programs these days come with their own updater tool, which can be installed to run with elevated permissions, so that program updates can be applied even though only standard users do ever log on to the system.
You have to decide whether your target audience can be assumed to run on power user or administrator accounts, or whether you will have to deal with above-mentioned problems. With Vista things got considerably harder already.
With all these problems (net access over proxies, missing write permissions for installation directories, the need to update files that the updater itself is using - just to name a few) I wouldn't try again to code this on my own. Much better to check if any one of the available solutions does all you need it to.
I use the Synapse routines GetHTTP to return a specific resource, and if found then check against the local system to see if an update is required. If so then the resource tells me what page to go to launch and I throw the URL into shell execute so the users
preferred browser is displayed.
Most of the time the download is a setup program created by InnoSetup which updates the users system and database to the latest version. When a new "paid" upgrade is needed, I then send the user to a "purchase upgrade" form. My web resources are ASP pages, so I can redirect to a different resource based on the customers version number.
For the main application (our application has a server piece, and a client piece) I have a loader which will check the server to see if the version of the client file on the server is different than the version on the client...if so, it prompts the user if the user wants to update/revert. We chose to prompt the user as sometimes an accidental bug might make it into the system and the user has to downgrade/upgrade only specific machines to help troubleshoot. I maintain a database record with the minimum version required which is updated via the database patch, so if a version must be retired then the record is updated accordingly.
I created my own solution too based on Indy for downloading and http://sourceforge.net/projects/makeupdate/ for file patching.
Before that I have used and tried several commercial tools, but no one was doing exactly what I needed.
I use TmxWebUpdate. It's free, simple and gives you good control over the process. I actually own TMS Component Pack with TWebUpdate but never really found a good reason to switch.
Edit: Link updated
We rolled our own as well. Its really not too difficult.
Our process goes something like:
When the main app is launched, it checks (using funcs from the synapse library) if there's an update available (assuming its configured to check, of course).
If so, it notifies the user and askes if they want to update.
If they do, it launches an updater .exe, and closes the main app.
The updater exe downloads the new files based on the contents of a text file it retrieves, keepiing the files in memory.
When the updater is done downloading everything correctly, it then saves the downloaded files to disk, backing up any files it replaces. This way if the download gets interupted, you dont end up with half the files installed.
Finally, it launches the main app again, and closes itself.
The trick w/ Vista is that you need to have an entry in the updater program's manifest to force it to run with administrator rights.
Normally we use the third party tool. But in some situations it was not usable so I created an own solution, which was pretty standard:
Get xml (or any other format) with update info.
If newer files are published, download and install them.
I use TWebUpdate . It works ok and has a ton of interesting options, but documentation isn't so great and I did bump into a few problems - which is why I download a full installer, instead of just the files...
I will be keeping an eye on this question, btw...
We use our own solution which follows these steps:
Application connects to http resource and downloads info file (ini text file) to memory, checks version number of newest release.
If newer version available, app downloads compressed binary package to exe location.
When download is finished, user is asked to restart application.
Upon start, application checks for presence of update package
App extracts package contents (usually a new app exe, but additional resources possible as well, e.g. updated language files etc.) - for each file it renames the current/old file to a temp name first, then extracts the new file. If the process fails at any point, the temp files are restored.
When finished, app executes new exe and closes itself.
No additional updater needed, the app exe can handle it all by itself.
For the compressed package we use our own update builder.
The package contains an index of files with a file hash, destination folder (relative path to main exe) and the compressed files.
During update we compare the stored hash with the extracted file to detect corupted files.
With Vista I see two solutions to enable Standard User Accounts to actually update the applications files:
Configure your setup to change permissions of the programs installation directory. This way files in "C:\Program Files (x86)\Your Company\You App" can be modified on Accounts with limited rights.
Example code for InnoSetup would be:
[Dirs]
Name: "{app}"; Permissions: users-modify
Install files that you plan to update to the ProgramData folder instead of the user defined directory and use this directory as an override folder. If files exist in ProgramData, use those, else check in install dir.
InnoSetup code:
[Files]
Source: "C:\Your Project\YourApp.exe"; DestDir: "{commonappdata}\Company Name\App Name\";
Same as "stg" and "GuyWithDogs", I'm using TWebUpdate from TMS. Although the documentation isn't so great, Its not so difficult to learnt.
With TWebUpdate, you have some options what the protocol you use, it could be done via HTTP, FTP or network access.
For communication layer, TWebUpdate uses WinInet. In some machines, the windows / IE URL cache can be frustating, so I've added a routine to clear the auto-update server address from cache first to ensure the information gathered from the server is up-to-date.