Weird issue regarding GetOwnerModuleFromTcpEntry when targeting x64 - winapi

Since I am a first time poster, I do apologize if I unintentionally left out any key piece of information, but here it goes.
Background: I am doing some testing to find out what the undocumented member array ‘OwningModuleInfo’ in MIB_TCPROW_OWNER_MODULE is and how it aid said function in determining what process owns the TCP endpoint. I have reached the conclusion that the first item in the array is the index of the service in the list of running services, which brings us to the weird issue. I am using Visual Studio 2012 (update 3) on Windows 7. The test app is running under UAC = requireAdministrator (asInvoker produces the same result, however).
Problem: When I target x64, then for some entries in the tcp table, GetOwnerModuleFromTcpEntry fails and returns “126 - The specified module could not be found.”. When I target Win32, this problem disappears. Since I know that this only happens when the entry is owned by a service, I tried the following dummy call just before the call to my test function (now targeting x64):
SC_HANDLE serviceManager = OpenSCManager(
NULL,
NULL,
SC_MANAGER_ENUMERATE_SERVICE);
CloseServiceHandle(serviceManager);
MyTestFunction(); // Prints the TCP table along with owner information
Now, it works just fine. Take the call to OpenSCManager away again, and it fails. Tell me that this is not really messed up?
I have reviewed every compiler and linker setting I could find.
I have double checked so I am linking to the proper libraries.
I created a C++/CLI version with identical code, which works fine both for Win32 and x64.
Checked for memory/alignment/pointer issues.
Sample output from test run without dummy call
Pid: 2896
Owner: Skype.exe
Pid: 848
Owner: Error 126 - The specified module could not be found.
Pid: 2896
Owner: Skype.exe
Pid: 3756
Owner: Error 126 - The specified module could not be found.
With dummy call
Pid: 2896
Owner: Skype.exe
Pid: 848
Owner: RpcSs
Pid: 2896
Owner: Skype.exe
Pid: 3756
Owner: WMPNetworkSvc
Short of this being a bug on Microsoft’ part, I am obviously missing something and I’m at the end of my rope. So if someone could nudge me in the right direction as to what I might be missing, it would be greatly appreciated.

The problem seems to be that advapi32.dll is not loaded. Said function seems to assume that advapi32.dll is loaded when calling it, which apparently is not always the case. I still do not know why advapi32.dll isn't loaded automatically, but I guess that is another question.
See this thread on the MSDN forum.

Related

missing ADO connection functionality when running old vb6 app on win 2016

*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.

Windows c++ service faulting on ucrtbase.dll when starting

So I've been developing this program for a while now... Its meant to act as an asset manager (and potentially more in the future) for our IT team. I have 2 services which we'll refer to as "Manager" and "IAM" for right now. The "Manager" does all things managerial for all services (currently only the inventory asset manager known as "IAM") such as automatic updates, etc., while the asset manager does its job.
Anyways, its been working great for a while now. Recently I implemented an automatic updating feature (actually still needing to be tested and likely debugged). While doing this, I needed to get my naming consistent (for example, renaming my service from "Updater" and "CppWindowsService" to the software's actual name).
Before this, it had been working great! Started, stopped, installed, and uninstalled with no hiccups. I change the name for everything, and make sure it all compiles ok. Looks good. Install works great for both "Manager" and "IAM" now, but as soon as I try to start it, I get:
StartService failed (1053)
Also, when I try to start it from services.msc, then I get the following error message:
Windows could not start the service on Local Computer.
Error 1053: The service did not respond to the start or control request in a timely fashion
The strange thing about this though is that it doesn't wait for any sort of timeout. It just instantly spits out the message. That message comes from the code called from my wmain() (windows entry point. main() otherwise.) function.
if (!StartService(
schService, // handle to service
0, // number of arguments
NULL)) // no arguments
{
printf("StartService failed (%d)\n", GetLastError());
CloseServiceHandle(schService);
CloseServiceHandle(schSCManager);
return;
}
else printf("Service start pending...\n");
In Windows Event Log, I get an application error containing the following details after fault.
Faulting application name: InITManager.exe, version: 0.0.0.0, time stamp: 0x59e11e44
Faulting module name: ucrtbase.dll, version: 10.0.15063.674, time stamp: 0x8ac9f9d4
Exception code: 0xc0000409
Fault offset: 0x000000000007350e
Faulting process id: 0x3008
Faulting application start time: 0x01d346915918e17d
Faulting application path:
C:\Users\collin.walker\Desktop\InITService\C++\x64\Release\Manager.exe
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
Report Id: 7fcbdcc4-be8e-476a-960f-4fa1fb21f892
Faulting package full name:
Faulting package-relative application ID:
Other info: ucrtbase.dll is used by Visual Studio and is associated with the Release build, where as ucrtbased.dll is associated with the debugger build. I am building in Release mode.
Now, I've already been told the issue isn't my code, but if anyone feels as though they need to see it, I will include it then. Its very straightforward c++ winapi stuff though.
If anyone has any further suggestions on how to troubleshoot this, please let me know, and thanks for all help in advance!
Kind of forgot about this post during my troubleshooting... Anyways, I figured it out. Comments above were spot on!
For me the buffer overflow came from me changing my service names, which also changed the program directory names. The error was happening when I was initializing my logging object in my service's constructor. I only have like 2 lines of code in the constructor, so I totally forgot to look there. Changed the hardcoded directory location where the log was being created, and it all started working great! Thanks guys for the helpful info!

Windows error on program start-up

I have an application written in Delphi XE3 (Originally Delphi 7) with a MySQL database. It was running on 5 computers on a network. Two of the computers were on windows 7 while 3 were still windows XP. The client recently upgraded the 3 windows XP computers to windows 7 x64 (3 brand-new identical machines). The program is running fine on one of the new computers but on the other 2 I get the error message "A problem caused the program to stop working. Windows will close the program and notify you if a solution is available". The program seems to crash at the end of the FormActivate procedure after it had verified the password and connected to the database. The MySQL server is up and running. I can access the database on the problem machines locally and remotely successfully.
I have searched the Internet and some websites suggest that this error is a protective mechanism from Windows triggered by a thread to system files, indefinite loops or memory problems – none of which are applicable to my program.
I have since reformatted the 2 problem computers and reinstalled Windows 7 again but it did not solve the problem.
The DependencyWalker output on both problem and working machines (and on my development machine) are identical :
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
With regard to different CPU types - in all instances the application is x86 and the rest of the modules are x64. This could be a 32-bit-64-bit problem but the program is running on all the machines except for 2 problem machines.
The Windows Event Viewer reports the following error:
Faulting application name: February_2014.exe, version: 1.0.0.0, time stamp: 0x52fa3b19
Faulting module name: KERNELBASE.dll, version: 6.1.7601.18229, time stamp: 0x51fb1116
Exception code: 0x0eedfade
Fault offset: 0x0000c41f
Faulting process id: 0x1510
Faulting application start time: 0x01cf28a57840f88d
Faulting application path: C:\dgpa dgr\February_2014.exe
Faulting module path: C:\Windows\syswow64\KERNELBASE.dll
Report Id: bd26ca27-9498-11e3-9479-7c050710b013
I have searched the Internet (and Stackoverflow) for KERNELBASE.dll but could not find anything useful.
I have asked for help on Windows Technet without success
http://social.technet.microsoft.com/Forums/windows/en-US/ef52b2e1-237d-436f-952f-7cdecdb48337/a-problem-caused-the-program-to-stop-working-windows-will-close-the-program-and-notify-you-if-a?forum=w7itprogeneral
The program is running without the hitch on my Windows 7 x64 development machine so I cannot replicate the problem/error that I am experiencing at my client. Has anybody had a similar problem? Any suggestions for the cause/trigger of the Error and how to solve it?
UPDATE
I got the following report from madExcept but I have no idea what it means
If you include a ClientDataSet in your application you need to deploy midas.dll with your application, or you have to manually add the MidasLib unit to your project's uses clause (for example)
program Project1;
uses
MidasLib,
Forms,
Unit1 in 'Unit1.pas' {Form1};
For a detailed explanation see the article of Cary Jensen on the topic.
The screenshot from madExcept is telling you that your program is raising an exception at startup, before you call Application.Run. The root of the exception is in the call to Application.CreateForm made in your project file.
The top-level exception handler is contained in the main application message loop that is implemented in Application.Run. Because you have not yet started the main application message loop, there is no exception handler.
This means that the exception leaks out of your application and the system has to handle it as best it can.
I don't know how to fix your specific problem, but the madExcept diagnostics tell you where to start looking. Ideally you would like to be able to debug this scenario in the IDE. Once you can do that it will be much easier to track down.
Fundamentally, if you leak exceptions out of your startup code, you will encounter such error dialogs.
I know of a few things that could be potential sources of the issue. First is the space (blank) in the path name where the application is running. Trying moving app to a subdirectory with no spaces in the path name. Second try running in Admin mode if you are not already. The answer that references "midas.dll" is another one. With the additional warning that Delphi used to install a copy of midas.dll in the Windows\System32 directory. Make sure that your version of midas.dll came with the version of Delphi you wrote the code in (and make sure that there isn't another older copy being found before the one you intended. Depends.exe can help show the path to the dll it loaded. Also have you tried running the app using "XP Compatibility"? Does the issue go away? Also have problems with DB components on a DataModule form in Delphi before. If you have a DB component with a AutoConenct on (or Streamed connection), it can cause unusual errors. Best to leave it disconnected and connect it in your source code at runtime. Last thing to try, look at the Windows services and see if the Performance Logs are running prior to launching your app. A weird one, but I've seen it.

GetUserNameEx fails with error 1114 (ERROR_DLL_INIT_FAILED)

I've shell extension for right click in Explorer. On certain machine with win 7 Ent SP1, GetUserNameEx called from QueryContextMenu() fails with GetLastError returning ERROR_DLL_INIT_FAILED. It was seen that GetUserName API also fails with same error code. The machine has alockout.dll (MS accout lockout tool) present on it.
Process monitor and Process Explorer do not indicate any sign of failure. Secur32.dll and alockout.dll were loaded successfully in Explorer (as seen from Process Explorer). When alockout.dll is not present, things work fine, i.e. GetUserNameEx returns the user name.
Can someone tell me what is going wrong over here? How to troubleshoot such problem? (any tool available to diagnose this problem further)
Note:
1. Similar post was already seen on MS blog with no response:
http://social.msdn.microsoft.com/Forums/en-US/983b5bec-dfe1-4f85-8123-86ec715ba484/when-getusernameex-fails-with-error-code-1114-errordllinitfailed
Discussed on CodeGuru forum. However, the solution/workaround used here cannot be used in my case.
http://forums.codeguru.com/showthread.php?517108-GetUserNameEx-returning-1114

Why does Vista complain about a dead process when I use Cygwin X11 ssh and how do I get it to shut up?

When I log into a remote machine using ssh X11 forwarding, Vista pops up a box complaining about a process that died unexpectedly. Once I dismiss the box, everything is fine. So I really don't care if some process died. How do I get Vista to shut up about it?
Specifically, the message reads:
sh.exe has stopped working
So it's not ssh itself that died, but some sub-process.
The problem details textbox reads:
Problem signature:
Problem Event Name: APPCRASH
Application Name: sh.exe
Application Version: 0.0.0.0
Application Timestamp: 48a031a1
Fault Module Name: comctl32.dll_unloaded
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 4549bcb0
Exception Code: c0000005
Exception Offset: 73dc5b17
OS Version: 6.0.6000.2.0.0.768.3
Locale ID: 1033
Additional Information 1: fc4d
Additional Information 2: d203a7335117760e7b4d2cf9dc2925f9
Additional Information 3: 1bc1
Additional Information 4: 7bc0b00964c4a1bd48f87b2415df3372
Read our privacy statement:
http://go.microsoft.com/fwlink/?linkid=50163&clcid=0x0409
I notice the problem occurs when I use the -Y option to enable X11 forwarding in an X terminal under Vista.
The dialog box that pops up doesn't automatically gain focus, so pressing Enter serves no purpose. I have to wait for the box to appear, grab it with the mouse, and dismiss it. Even forcing the error to receive focus would be a step in the right direction.
Per DrPizza I have sent an email to the Cygwin mailing list. The trimmed down subject line represents my repeated attempts to bypass an over-aggressive spam filter and highlights the need for something like StackOverflow.
The problem is, the process didn't just die, it died unexpectedly. Sounds like there's a bug in your SSH client that Vista is pointing out.
I know this is going to be heresy for a cygwin user, but you could just use PuTTY instead.
What does unexpectedly mean in this context? Does it mean it core dumped or just exited non-zero?
It means it died with an unhandled exception, i.e. it crashed.
Fault Module Name: comctl32.dll_unloaded
Exception Code: c0000005
Something had triggered loading of comctl32.dll, but it was later unloaded.
c0000005 means 'access violation'. Probably something tried calling a function in the unloaded dll.
I agree with one of the cygwin commentators that it's possibly a bug in some antivirus program or "desktop enhancement" software. Video card companies like to inject their stuff into every process, too. It's easy to use comctl32.dll for things without realizing it, however.
Try downloading and installing WinDbg from Microsoft. http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx Set it as the default JIT debugger "windbg.exe -I". Next time this happens you should get the nice debugger window pop up. Type "kv100" to get a stack trace. Look at the dlls listed in the calling path, there's a good chance one of them is the culprit.
If you see a dll that's not from Microsoft or Cygwin there, uninstall that application and see if the problem goes away. Otherwise, the Cygwin list might be interested in the stack trace.
Well, I don't know what the original problem was, but when I update Cygwin recently the error message stopped popping up.
My guess it that rebasing was necessary.

Resources