I wrote a windows service it it works and STARTS fine in most operating systems. I have narrowed down the fact that Windows 10 upgraded from windows 8 causes a problem where the service does not start on reboot when the service is set to automatic.
I find that start delayed does work ok.
Wondered if anyone knew of nuances between a full from scratch install and an upgrade that might point to the narrowing in on this elusive issue.
When it does not work there are no logs or events generated. It does not seem to try and fail - just not run (start).
I just came across an installation where it works fine and the OS was upgraded from Win 8. There seems to be some dependency that is different. The service was written against .Net Framework 4.0 x86.
The service starts manually just fine.
automatic (at boot) startup does not work. I was about to say it fails - but that is not the case as it does not seem to even be trying.
We had a similar issue with windows 10 where most .Net based services would fail on startup, but could be started later manually just fine. For some reason, services that are written in .NET take longer to start in Windows 10. By default, if a service takes longer than 30 seconds to start without responding, the service is terminated by Windows.
I was able to change that behavior to 60 seconds in the registry. Go to:
HKLM\SYSTEM\CurrentControlSet\Control\
If it doesn't already exist, create a DWORD (32-bit) key called "ServicesPipeTimeout"(minus quotes). Set its value to 60000(in decimal). This correlates to 60 seconds in milliseconds.
I even created a regfile to automate this:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control]
"ServicesPipeTimeout"=dword:0000ea60
Just paste into notepad and save as a .reg file.
This is not a delayed start, but an increase in the time given to services to respond after startup. This fixed the issue for us on multiple machines. Unfortunately, I still do not know why .NET services take so long to start that they get terminated. However, I feel this is a Microsoft bug, and not necessarily anything us users are doing wrong...
We have a similar issue where one of our services (.net) does not start automatically in some cases after upgrading to Windows 10. Also, in a number of situations the problem was solved after updating to Windows build 10.0.10240; not in every case though. No errors in the event log either.
Update: a delayed start also seems to work in some cases.
We also have the same problem with a C++ windows service that we created. Automatic startup works fine for most people. However we have 5 instances now where the customer's service was working fine and now it will not automatically start up.
The only thing that seems to work is setting to delayed start, but this is not a good option as we would like the service to be started right away. We've also tried adding service dependency of NetLogon - which did not work.
Also note that this was working fine for customers and at some point (windows update maybe?) it just stopped automatically starting.
The customers are also able to go into services and start the service manually, and it works. I'll be following this thread and hoping for a better solution than delayed start.
What fixed it for us is, if you can change the service executable yourself:
In the project file change the Prefer 32-bit flag to false, then reinstall the service.
Check your service with CorFlags.exe. The 32BITREQ and 32BITPREF should be 0.
Version : v4.0.30319
CLR Header: 2.5
PE : PE32
CorFlags : 0x1
ILONLY : 1
32BITREQ : 0
32BITPREF : 0
Signed : 0
Related
*THIS HAS BEEN EDITED, SEE BOTTOM. I CHANGED THE TITLE TO BETTER REFLECT THE PROBLEM.**
I have an old vb6 application that I put on a windows 2016 server and been having issues with dependency files. I ran process monitor and started putting the dll files in the locations where it is looking at, most of them have cleared up.
I'm getting one that I cant find on the old win 2000 box or anywhere else: wow64log.dll
Where can I can get this file? I attached pics of proc mon and the list of dependencies that the app is requiring. any direction would be appreciated. third pic is the actual error when trying to open the app. edit added the dependency walker screen shot
EDIT***
so I have narrowed down the issue and it boils down to an ADO connection. I cant seem to connect on windows server 2016 using ADO. I suspect it has something to do with the connection string, but what baffles me is why does this work on a win 10,1803 box and not on windows server 2016 1607 ?
this is basically my issue - https://social.msdn.microsoft.com/Forums/SECURITY/en-US/f1eee40b-6ab2-445f-a361-ae965439273a/run-time-error-214746725980004005-for-using-adodbconnection?forum=isvvba
I suspect that this is not an actual error in the runtime of your program, If you are only looking at Procmon, be aware that it shows a lot of stuff and sometimes not all the "errors" there are really relevant. For instance, it will often show how Windows functions look in a long list of search paths, each failing in turn, before that actual location of a DLL is detected.
In this case, it seems most likely that a missing wow64log.dll is harmless and apparently, totally normal.
"WoW64" is the Windows subsystem which runs 32 bit programs inside the 64 bit operating system. ("WoW" stands for "Windows-on-Windows".)
According to the reference WoW64 Internals describing how this subsystem is initialized:
wow64!ProcessInit
...
It … tries to load the wow64log.dll from the constructed system
directory. Note that this DLL is never present in any released
Windows installation (it’s probably used internally by Microsoft for
debugging of the WoW64 subsystem). Therefore, load of this DLL will
normally fail. This isn’t problem, though, because no critical
functionality of the WoW64 subsystem depends on it.
Although that article is talking about the ARM64 architecture (which AFAIK is not what most PCs would be using) it sounds like much of the WoW64 system is similar to normal PCs.
I want to use the Windows User-Mode Scheduler API but every sample C or C++ I have found in the internet fails. Invariably I get ERROR_NOT_SUPPORTED.
My Computer is running Windows 10 Pro 64-bits in an x64 processor. I am using VS2015 and the application is an x64 console application.
Notably not every call fails, in the 4 samples I've tested either
EnterUmsSchedulingMode
CreateRemoteThreadEx
Fail with ERROR_NOT_SUPPORTED. Those are necessary to get things going, but for example CreateUmsCompletionList or GetUmsCompletionListEvent do not.
The API is not trivial to use but I am having a hard time believing all of them are wrong.
I've debugged a bit what happens inside EnterUmsSchedulingMode and it seems that things go wrong when calling NtSetInformationThread inside RtlpAttachThreadToUmsCompletionList although of this I am less sure.
Here is one and here is another of the samples I've tried.
If you're on a pre-Ivy Bridge processor UMS will fail to work due to a potential security problem where an LDT is created on x64. The problem can be avoided with Ivy Bridge and a Windows 10 (and ostensibly Server 2016) update simply disables the UMS feature if the processor doesn't have access to the Ivy Bridge feature.
More info here: http://www.alex-ionescu.com/?p=340
I programmed a Windows Service and it is running on a Windows 2000 machine. Sometimes the executable for this service dies, but the Windows service is still listed as "started" in the service manager. In this situation the restart behaviour defined for this service does not take effect.
Of course, the process needs to be debugged, but I am searching right now for a workaround.
How can I avoid this situation? How does the service manager in Windows 2000 determine if a windows 2000 process is still started or not?
That probably means that the service crashed. IIRC, older versions of windows didn't always recover when a service process abnormally terminates. But that was many years ago and my memory may be faulty.
The best way to avoid the situation is to figure out what's causing your service to crash and fix it.
Although Larry, being a Microsoft employee, probably knows better than anyone else, I dare say that you should give ChangeServiceConfig2 with SERVICE_CONFIG_FAILURE_ACTIONS a shot. I've worked on a legacy service that, before I did the refactoring, used to crash a lot. The remedy my predecessors chose was to use the failure action in order to invoke a program that (running under SYSTEM) would then restart the service as if nothing had happened.
All of this only works if your service is running in its own process, which I assumed given the way you describe it. If your service is implemented in a DLL this will not work.
But I wholeheartedly agree with Larry that you should investigate and fix the problem, rather than trying to conceal it. As mentioned above, I fixed the service in question and it's not crashing or very rarely crashing and everyone is happier with that solution ;)
I'm debugging plugins on Windows 7 and of course the plugin host (Cubase5.exe) occasionally crashes because of errors in the plugin. On XP or Vista, I could always restart it immediately and continue working. But on Windows 7, even though Cubase appears to close, it is still visible in Task Manager and I cannot kill it by any means. After a minute or two, it disappears by itself. In the mean time, I can't work because the plugin DLL is still locked by the process.
Does anyone know why this happens on Windows 7? I've already tried disabling Automatic Error Reporting but that didn't help. I've tried attaching cdb to Cubase, but I get:
Cannot debug pid 5252, NTSTATUS 0xC0000001
"{Operation Failed} The requested operation was unsuccessful."
Debuggee initialization failed, NTSTATUS 0xC0000001
"{Operation Failed} The requested operation was unsuccessful."
I tried following the instructions here but it appears this is only possible if I connect a second machine to my computer to debug it remotely.
I finally found the solution, using this article:
http://blogs.technet.com/b/markrussinovich/archive/2005/08/17/unkillable-processes.aspx
This required installing the Windows Debugging Tools for Windows (nice name) and LiveKd, but by following the steps outlined I was able to track which driver was causing the process to hang: it turned out to be the 64-bit driver for the M-Audio Oxygen 8 V2 controller I'm using. Unfortunately no driver update is available.
Anyway, if anyone encounters a similar problem, this is the way to solve it.
Have you tried Process Explorer by Mark Russinovich? It is really useful for "killing":)
If you have error reporting enabled, it's possible that werfault.exe has Cubase open to write a minidump for crash reporting purposes.
This is just a stab in the dark but it might be your problem.
One thing you can try is to check with Process Monitor what Cubase is doing. Set a filter so that everything with a process name containing "cubase" will be recorded. It could be that you are facing some timeout issue when Cubase wants to exit.
you can end the process the service is running under. You can find this process by going to the Services tab of the Task Manager, right-clicking, and selecting Go To Process(you need to click the Show processes from all users button.). Note that one process may host multiple services (especially if it's svchost.exe), and ending the process will kill all those services. Also, this is an unclean exit, and may cause data corruption depending on what the service(s) was doing when you killed it.
Depending on which specific service you are trying to stop, there may be a cleaner way to simulate failure.
Windows 7 is caching some of the COM class information. Older OSs didn't do this. After the OS looks up theHKCU\Software\Classes\CLSID\{GUID}\LocalServer32 value, it caches the value, and doesn't look it up again.
When we update our software, we place the new updates in a different directory, and then update the HKCU\Software\Classes\CLSID\{GUID}\LocalServer32 value to reflect the new path. The next time the software runs, it will use the latest files if running under older Windows OSs. However, on Windows 7, it will continue to use the older file, until the OS is rebooted.
I ran process monitor, and discovered that under Windows 7, it never reads the registry key again, after the first read. On older OSs, it reads that key every time.
My question is: Is there any way to force Windows 7 to re-read the LocalServer32 information from the HKCU hive each time a new out of proc COM object is created?
I have only been able to solve this problem by...
1: Stopping the Process
2: explicitly unregistering using regsvr32 the library ( or exename /unregserver)
3: Registering the new component
4: Starting the process back up.
I would suspect that it is the Un Reg part that is failing for you. If you are just changing the registry key directly then you should call RegSvr32 /u instead.
Also make sure the new directory location is the current directory when you call RegSvr32.
Note that I have always stopped the process and then unregistered, this is probably a significant detail.
As this is a top result in Google for this narrow-ish problem, I thought it would be valuable to add my troubleshooting outcome for this problem.
I found this response on SO: C# : How to change windows registry and take effect immediately
And linked solution from that answer: Registry Watcher C#
Both of which seem viable options for managing changed keys without forcing a reboot. For us (like the OP) this was when installing updates. For us (possibly unlike the OP) this is infrequent and we decided the effort to implement and test a fix as described was outweighed by the simple solution of requiring a reboot: a process Windows users have come to expect with installing software anyway.