I have installed, apparently successfully, com0com v2.2.2.0 on a 64bit Windows 7 machine.
I run the command utility, like this:
command> install PortName=COM9 PortName=COM8
CNCA0 PortName=COM9
CNCB0 PortName=COM8
ComDB: COM8 - logged as "in use"
ComDB: COM9 - logged as "in use"
command> busynames COM?*
COM3
COM4
COM5
COM6
COM8
COM9
COMPOSITEBATTERY
Note: logged as "in use" is NOT an error message?
Then I try to open COM8 like this
m_hIDComDev = CreateFileA( szCodedPort, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_OVERLAPPED, NULL );
if( m_hIDComDev == NULL || m_hIDComDev == INVALID_HANDLE_VALUE ) {
wchar_t * lpMsgBuf;
DWORD dw = ::GetLastError();
FormatMessage(
FORMAT_MESSAGE_ALLOCATE_BUFFER |
FORMAT_MESSAGE_FROM_SYSTEM |
FORMAT_MESSAGE_IGNORE_INSERTS,
NULL,
dw,
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
(LPTSTR) &lpMsgBuf,
0, NULL );
myErrorMsg = (char*)malloc( 200 );
sprintf(myErrorMsg,"Error creating connection %s ( %s ) %S",
szPort,szCodedPort,lpMsgBuf);
This fails with
Error creating connection COM8 ( COM8 ) The system cannot find the file specified.
I have tried both "COM8" and "\\.\COM8".
Note that the exact same call to CreateFileA works perfectly on a 'real' COM port.
Q: Can someone tell me what the problem is?
A: On windows 7 64 bit you have to enable testing of unsigned drivers.
Run a command prompt as administrator. ( It is not enough just to run from an account with admin privileges. See here for details of how to do this. )
Type in the command bcdedit -set TESTSIGNING ON
reboot. ( Windows will place a "test Mode" note on the bottom right of the desktop )
For Windows 8 this method does not work satisfactorily or easily. Here is some discussion of the issues and workarounds.
Alternatively you might want to try a signed version - I have NOT tried this myself.
In case anyone is referencing this, and interested in this topic, the 2.2.2.0 version of com0com is signed for 64-bit Windows. This removes the need to jump through the hoops of putting Windows in "test" mode.
Here are my points:
Microsoft requires 64-bit drivers to be signed.
com0com.sys (64bit) is a mere unsigned kernel-mode driver.
SoftWx has written an interesting tutorial on installing it on a 64 bit Windows 7 machine. You can fetch it here.
This is a very old post, but just to add some help if somebody stumbles across it like I did.
After Windows 10 Version 2004 you may need to disable Secure Boot in your BIOS.
I got a signed version 3.0 of the app from SourceForge, this worked perfectly on my one PC (Windows 10 Pro Version 2004). I just installed the app and two pairs of linked ports were immediately created.
On my laptop (Windows 10 Pro Version 20H2), I did not get the same results. No COM ports were created and in the device manager the devices could not be configured. After changing the BIOS setting, I reinstalled and all went smoothly.
Links for reference:
https://sourceforge.net/projects/com0com/
https://sourceforge.net/projects/signed-drivers/files/com0com/v3.0/
To answer #DaAwesomeP above (I do not have the rep to put it in the comments), there is a repo on GitHub https://github.com/paulakg4/com0com where I can see a changes.txt. If I compare the dates, it looks like the same version 3.0 in there.
Related
System: Windows 10 20H2 Enterprise SAC
PowerShell: 5.1.19041.1320
Windows ADK: 10.1.19041.1
If i run the PowerShell CmdLet "Export-WindowsImage", everything works as expected, except that the name for the image is not changed in the new image file if i use the parameter "-DestinationName".
Example:
Export-WindowsImage -SourceImagePath install.wim -SourceName "Windows 11 Enterprise N" -DestinationImagePath export.wim -DestinationName "Windows 11"
Get-WindowsImage -ImagePath export.wim
ImageIndex : 1
ImageName : Windows 11 Enterprise N
ImageDescription : Windows 11 Enterprise N
ImageSize : 15.721.845.834 bytes
Logfile doesn't help either, all this CmdLet logs in the dism logfile is this, no matter what loglevel i use:
Initializing wimgapi.
Shutting down wimgapi.
When i export the image via DISM & "/DestinationName", it works as expected, and the image is saved with it's new name in the new file.
I think i ran into this issue before and that's why i ended up dropping PowerShell for my WIM shenanigans. I just tried again and this still appears to be a thing, must have been at least 3 years now.
This issue has been reported to Microsoft, but didn't really net any fruitful help:
https://github.com/MicrosoftDocs/windows-powershell-docs/issues/1194
Sadly i can't find any other information relating to this problem.
Assuming that this is a bug, where would be the correct place to report this to Microsoft, if such a place even exists?
Or is there anything obvious i am missing here?
I have a Windows service (running on Windows Vista+), which needs to launch a normal GUI application. For some reason, I need to run the GUI application on non-default desktop (of course, since it's launched by the service process, it runs in Session 0, WinSta0, but not on the Default desktop).
The code looks like this.
// create new desktop
hDesktop = CreateDesktop(NEW_DESKTOP, 0, 0 ,0,
DESKTOP_SWITCHDESKTOP | DESKTOP_WRITEOBJECTS |
DESKTOP_READOBJECTS | DESKTOP_ENUMERATE |
DESKTOP_CREATEWINDOW | DESKTOP_CREATEMENU|
DESKTOP_HOOKCONTROL, &sa);
// create process of the normal GUI application,
// running on the new desktop, not the default one
STARTUPINFO si;
ZeroMemory(&si, sizeof(si));
si.cb = sizeof(si);
si.lpDesktop = NEW_DESKTOP;
ZeroMemory(&processInfo,sizeof(processInfo));
BOOL bRet = CreateProcess(NULL, &commandLine, NULL, NULL,
FALSE, 0, NULL, NULL, &si, &processInfo);
TCreateProcess(...) method returns successfully, but the GUI application exits immediately after launching. With help from Gflags, I got following information.
LdrpInitializeRoutines - Error: Init routine 7595D711 for DLL "C:\Windows\system32\USER32.dll" failed during DLL_PROCESS_ATTACH
_LdrpInitialize - ERROR: Process initialization failed with status 0xc0000142
LdrpInitializationFailure - ERROR: Process initialization failed with status 0xc0000142
I searched for a while, seems it's related to security issue. I tried to grant all desktop related rights to current user, but it didn't help.
One thing may help. I noticed that there are a few DLLs were not loaded when running with SYSTEM account, the first one is uxTheme.dll.
Anyone has any idea why it doesn't work with non-default desktop, while working well with default desktop?
Thanks.
You need to use CrateDesktopEx and increase the size of heap -- the default is not sufficient even for the notepad.
The win32 API SearchPath API fails to find the "telnet.exe" binary path even though its present in system32.
However when I did a search for notepad.exe, with the same code it returns the file path. What puzzles me here is that both notepad.exe and telnet.exe lies in the same directory i.e C:\windows\system32.
This is the code I have written
char path[MAX_PATH] = {0};
LPSTR* ptr = NULL;
DWORD dwRet = SearchPathA(NULL, "telnet.exe",
NULL, MAX_PATH, (LPSTR)path, ptr);
This would always return 0 and the GetLastError is 2 ( File not found)
Any idea what is happening here?
I am using windows 2008 R2 enterprise edition on an x64 machine
Thanks & Regards
Sunil
It's not working because you application is 32 bit and is being affected by the File System Redirector. Your application is not looking in C:\Windows\System32 but is instead being redirected to C:\Windows\SysWow64.
notepad.exe exists in both System32 and SysWow64, but telnet.exe only exists in System32. So you application does not find it when it searches the path.
You can disable this behavior for your application by calling Wow64DisasbleWow64FsRedirection. But note the warnings in the documentation links that indicate that this should only be disabled temporarily and then re-enabled.
When installing a signed driver (i.e. with a properly signed .CAB) on Windows 7 through DpInst, unless it's a WHQL-signed driver, you cannot install it silently. If you run DpInst in the non-silent mode, it'll prompt you to trust the "publisher". If you run DpInst in silent mode, it would fail with a signing-related error code (something like 0x800b0109 -- check your setupapi.app.log).
While ilya's answer is good, the solution on Windows 7 is even easier. The command below deploys the certificate to both the current user and the system trusted publisher certificate stores. It requires administrative privileges and is provided by Microsoft.
For Windows 7
certutil.exe -addstore TrustedPublisher cert.cer
I verified that this works on Windows 7 64-bit to deploy signed, but not WHQL-certified, drivers - without prompting the user.
Windows XP
WHQL Certification
It appears that on XP you still need to have the drivers WHQL-certified in order to avoid prompts on install.
Pre-Installing SPC on Windows XP
For Windows XP you'll need to download the Windows Server 2003 Admin Tools Pack from Microsoft and extract certutil.exe and certadm.dll. Then the command above will work on XP as well.
Admin Tools Pack: http://www.microsoft.com/download/en/details.aspx?DisplayLang=en&id=16770
Note that the extracted msi file can be inspected by 7-zip, so you don't need to install it to obtain the exe and dll you need.
The straightforward way to do it is to add the signing certificate to the TrustedPublishers. You can do it programatically (the implementation of win32exception is left as an exercise to the reader):
#include <windows.h>
#include <wincrypt.h>
#include "win32exception.h"
void InstallTrustedPublisherCertificate(LPCTSTR CertificateFilePath)
{
DWORD dwContentType;
PCCERT_CONTEXT pCertContext = NULL;
if (!CryptQueryObject(
CERT_QUERY_OBJECT_FILE,
CertificateFilePath,
CERT_QUERY_CONTENT_FLAG_ALL,
CERT_QUERY_FORMAT_FLAG_ALL,
0,
NULL,
&dwContentType,
NULL,
NULL,
NULL,
(const void **)&pCertContext))
throw win32exception("CryptQueryObject");
if (dwContentType != CERT_QUERY_CONTENT_CERT)
throw exception("Incorrect content type of crypto object.");
__try
{
HCERTSTORE hCertStore = CertOpenStore(
CERT_STORE_PROV_SYSTEM,
0,
0,
CERT_STORE_OPEN_EXISTING_FLAG |
CERT_SYSTEM_STORE_CURRENT_USER,
_T("TrustedPublisher"));
if (hCertStore == NULL)
throw win32exception("CertOpenStore");
__try
{
if (CertAddCertificateContextToStore(hCertStore, pCertContext, CERT_STORE_ADD_NEWER, NULL))
{
// Added certificate to TrustedPublisher store.
}
else
{
DWORD err = GetLastError();
if (err == CRYPT_E_EXISTS)
{
// Certificate already exists in TrustedPublisher store.
}
else
throw win32exception("CertAddCertificateContextToStore", err);
}
}
__finally
{
CertCloseStore (hCertStore, 0);
}
}
__finally
{
CertFreeCertificateContext(pCertContext);
}
}
And the question is? If the driver is not WHQL-certified, it can't be installed silently. This is a security measure of Windows.
The Drivers have to go through WHQL Certification to avoid any kind of un-signed pop-ups.
If you are looking for any third-party WHQLTesting Service providers let us know, we would be happy to help you in this regards.
I'm having problems trying to run a bunch of old 16-bit applications in Windows 2008 Server.
The applications ran fine up to Windows 2003 Server, but when I try to print from any of
them, all show printing errors (Unable to create printer driver / TERM error / etc)
The LPT1 port is redirected to a shared printer via NET USE LPT1 \ServerName\SharedPrinter
DIR > LPT1 (or any shell redirection to the printer) is working fine.
I'm using an Administrator account, so it shouldn't be a permissions problem, right?
To reproduce the behavior, I made a small test program in C (TCC 1.01 for DOS). It runs fine
in XP / 2003 Server, but on 2008 Server it shows the handle opening (5) but when is trying
to write in that handle, issues an error (Write fault error writing device LPT1, Abort, Retry,
Ignore, Fail)
#include <io.h>
#include <fcntl.h>
#include <sys\stat.h>
int main(void)
{
int handle, status;
char* sbuff;
handle = open("LPT1", O_WRONLY, S_IFBLK);
printf("%d\n", handle);
if (!handle)
{
printf("open failed\n");
exit(1);
}
sbuff = "[print test]\n";
write(handle, sbuff, strlen(sbuff));
close(handle);
getch();
return 0;
}
Any clues?
TIA,
Pablo
Mike A - I have discovered that syntax 'print /d:{lpt?} {filename}' is not working on Win2008, not from within a 16bit app OR from the command line. This syntax has been supported for years and we run it in 10 Win2003 servers. Might there be a configuration setting in Win2008 that would make it syntax compatible with previous versions of Windows? BTW, here is Microsoft Tech Bulletin that was updated April 2012 that list the syntax as being compatible with Win2008... http://technet.microsoft.com/en-us/library/cc731623.