Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

TPIPE: Error -Can´t access textpipeengine.dll

Jun
46
1
Version 21.00.37 (and 21.00.34 and may be more) on Windows 10 64 bits, fails to run Tpipe with the message TPIPE: Error -Can't access textpipeengine.dll.

It was not a problem of path. I solved it by copying the file tpipe.exe from a previous version (21:00.28).

Regards,

OPH. 2017-07-19
 
Same here on Windows 7.
Code:
0:00:00.01
[C:\BIN\JPSoft\TCMD21]
13:06:42 $ ver

TCC  21.00.37 x64   Windows 7 [Version 6.1.7601]

0:00:00.00
[C:\BIN\JPSoft\TCMD21]
13:06:43 $ tpipe
TPIPE: Error - Can't access textpipeengine.dll
 
You might try, ELEVATED, and with v21's install directory as current directory ...
Code:
regsvr32 textpipeengine.dll
 
I can't elevate this computer.

Edit: And trying to register it for current user gives
Code:
C:\BIN\JPSoft\TCMD21>regsvrex /c textpipeengine.dll
Error occured registering server - %1 is not a valid Win32 application.
 
Code:
[]ver

TCC  21.00.36 x64   Windows 10 [Version 10.0.15063]
Copyright 2017 JP Software Inc.  All Rights Reserved
Registered to

[]tpipe
TPIPE: Error - Can't access textpipeengine.dll

Is this an indication of how many really use tpipe? :smile:
 
This has nothing to do with blocking COM DLL's. It's an developer's error (actualy: multiple errors).

@JohnQSmith : If you need it, I can give you a non elevated workaround for this.
But it is (way) better to wait for a next version of TCC where this gets properly fixed.
 
I tried to run TPIPE, but Norton Security identified it as a Trojan and quarantined TPIPE.EXE. Here are the details reported by Norton Security.............



Filename: tpipe.exe
Threat name: Trojan.Gen.7Full Path: c:\program files\jpsoft\tcmd21\tpipe.exe

____________________________

____________________________


On computers as of
7/19/2017 at 4:10:25 PM

Last Used
7/22/2017 at 4:21:44 PM

Startup Item
No

Launched
No

Threat type: Heuristic Virus. Detection of a threat based on malware heuristics.


____________________________


tpipe.exe Threat name: Trojan.Gen.7
Locate


Few Users
Fewer than 50 users in the Norton Community have used this file.

Very New
This file was released less than 1 week ago.

High
This file risk is high.


____________________________


Source: External Media

Source File:
130af97f.msi

File Created:
1afa9d69.msi

File Created:
c1ec897.msi

File Created:
tpipe.exe

____________________________

File Actions

File: c:\program files\jpsoft\tcmd21\ tpipe.exe Removed
____________________________


File Thumbprint - SHA:
4653e5eaa0e953c6b0156877ff8d079ba34b4e5230a72262f675f042f6ed062e
File Thumbprint - MD5:
fdd5962137c9371e2b1415ea3d02b520
 
I tried to run TPIPE, but Norton Security identified it as a Trojan and quarantined TPIPE.EXE. Here are the details reported by Norton Security.............
I once used an antivirus (not Norton) which regularly had false positives for bits of Take Command. Annoying, until I found the option to exclude Take Command's install directory from scanning. I'll bet Norton has a similar option somewhere.
 
Code:
TCC  21.00.37 x64   Windows 10 [Version 10.0.15063]

This question is probably an artifact of my ignorance but what is the recommended method to deal with this problem?"
  • Copy the necessary file(s) from a earlier version of TCC
  • Register textpipeengine.dll from the current version of TCC
  • Find alternate utilities to provide the tpipe functions I actually use
  • Wait for a subsequent version of TCC [probably the smart option :smile:]
 
Code:
TCC  21.00.37 x64   Windows 10 [Version 10.0.15063]

This question is probably an artifact of my ignorance but what is the recommended method to deal with this problem?"
  • Copy the necessary file(s) from a earlier version of TCC
  • Register textpipeengine.dll from the current version of TCC
  • Find alternate utilities to provide the tpipe functions I actually use
  • Wait for a subsequent version of TCC [probably the smart option :smile:]

Register textpipeengine.dll with regsvr. (We would do that by default, but a lot of users have their systems locked down by IT so that they can't register any COM dll's, and trying to causes the installer to fail.)
 
Register textpipeengine.dll with regsvr. (We would do that by default, but a lot of users have their systems locked down by IT so that they can't register any COM dll's, and trying to causes the installer to fail.)

As always thanks for your prompt and professional response! :smile:
 
@rconn - then could the installer say that the user has to run the command themselves and if it does not succedd then what to do please?
 
And just to rule out the Norton Security issue I had for TPIPE.EXE, could someone at JPSoft please post the SHA1, SHA256, and/or the SHA512 checksum for (a known clean and trusted copy of) the TPIPE.EXE file? I'm pretty sure Norton was giving a false alarm, but if I restore the quarantined file and run %@SHA256 (or whatever %@SHA* function) on it and can compare it to the one someone at JPSoft posts to this thread, I could confirm for sure that the file is legit (and thus not altered by any (unlikely but possible) malware that might be on my machine).

The version in question is for TCMD 21.00.37 x64
 
Last edited:
Code:
[C:\Program Files\JPSoft\TCMD21]ver & echo %@sha512[TPipe.exe]

TCC  21.00.37 x64   Windows 7 [Version 6.1.7601]
0C3C2A56B26BA6D26CA26850707CBFA8AD6530E481FD84F1203F48FA08E454BABAD16B556F42C9857AAB8AA8407B74E9B0362E4334AAD4792F3246EC88FE17EB

[C:\Program Files\JPSoft\TCMD21]
 
Register textpipeengine.dll with regsvr. (We would do that by default, but a lot of users have their systems locked down by IT so that they can't register any COM dll's, and trying to causes the installer to fail.)

So many wrongs .. where to begin ...


textpipeengine.dll does *NOT* have to registered.
It is a registration-free COM component (also known as isolated COM).

textpipeengine.dll is provided by another company (datamystic) and TPIPE.exe is jpsoft's "interface" between this DLL and TCC (although TPIPE.exe can also be run standalone, without TCC).
The only reason textpipeengine.dll has to be registered now (it was never needed in the past) is because of programming errors in the current version(s?) of TPIPE.exe.
That's why replacing TPIPE.exe with an older version "repairs" it: now TPIPE can be run *without registering the DLL*.

Registering this DLL is a "Plan B" fail-save mechanism of Window to be able to address the DLL in a different way.


There is no such thing as COM blocking.
COM components are a core functionality of modern Windows. If it is blocked, most applications (including Office) and large parts of the operating system won't work anymore.
On my systems I have blocked access to "my" COM components from external systems (that is a often overlooked security leak: a lot of COM components have lousy security settings, which makes it possible to access files and functions on my system from any system). But I seriously doubt that a lot of companies/people have it setup this way. Or even heard about it ...

But registering a DLL requires administrative rights. In most companies the employees run their programs as a "regular" user. That's why the DLL should be registered during installation (*if* it needs registration)


Installer fails on registering the DLL?
It took me literally less than 10 minutes to extract the MSI from the installer, break open the MSI (using Orca), add DLL-registration functionality, save the MSI and run the extracted MSI ( yes, that is possible: msiexec.exe /i tcmd.x64.msi SETUPEXEDIR="." )
This registered the DLL on install and unregistered it on uninstall without any problems whatsoever (and my system is probaly more locked-down than most).
Ergo: the Windows Installer technology can handle this situation without issues. If it does fail, it is most likely a human error.


a lot of users have their systems locked down by IT
I'm probably biased, but I can't imagine Take Command being used in companies very much...

Part of my job is to advise companies about their application landscape.
Take Command is one of those applications I would advise against using it in a corporate environment.
Personal use: fine; using it as part of your company's workflow: deprecate it as soon as possible.
 
So many wrongs .. where to begin ...

The only reason textpipeengine.dll has to be registered now (it was never needed in the past) is because of programming errors in the current version(s?) of TPIPE.exe. That's why replacing TPIPE.exe with an older version "repairs" it: now TPIPE can be run *without registering the DLL*.

No.

The TPIPE source hasn't been changed in months.

The reason that textpipeengine.dll had to be registered (in one build; fixed a couple of weeks ago) is because of the recent switch to VS2017 for building TCMD, which exposed a bug in the manifest tool that affected a limited number of systems. Reverting to VS2015 resolved the problem. (And a VS2017 patch has now resolved it there too.)

There is no such thing as COM blocking.
COM components are a core functionality of modern Windows. If it is blocked, most applications (including Office) and large parts of the operating system won't work anymore.

Misleading and not particularly relevant - my statement on this topic was that many corporate systems block registration of (unapproved) COM dll's during installation, not that apps couldn't use COM dll's after they had been installed.

But registering a DLL requires administrative rights. In most companies the employees run their programs as a "regular" user. That's why the DLL should be registered during installation (*if* it needs registration)

Installers always run elevated (that's built into Windows). But as I said, registering the dll during installation caused numerous (as in hundreds) of complaints from users running on corporate networks, due to Windows Policy settings. That's why I created the registration-free manifests (several years ago) for textpipeengine.dll.

a lot of users have their systems locked down by IT
I'm probably biased, but I can't imagine Take Command being used in companies very much...

Currently, about 87% of TCMD users are corporate users. (Not including TCC-RT, which is intended primarily for corporate users. We don't generate any usage / registration info for TCC-RT.)

The remaining 13% are a mix of home, small business, and some people buying it themselves to use on their company computer.[/QUOTE]
 
What's the bottom line? Does it have to be resistered or not? I registered it and that fixed the recent problem. Can I now unregister it?
 
What's the bottom line? Does it have to be resistered or not? I registered it and that fixed the recent problem. Can I now unregister it?

The bottom line is that it doesn't matter. You don't need to register it, you don't need to unregister it.

The only caveat is that if you're running multiple versions of textpipeengine.dll, then you don't want to register it.
 
The problem seems to be fixed in v21.00.39 (running Windows 8.1 Pro x64). v21.00.37 was giving me the error. Referring to the "Error -Can´t access textpipeengine.dll" error, not my antivirus issue (which I found a workaround for now).
 
Last edited:
No, it's not.

There is no such thing as a "registration-free COM component". There *is* such a thing as "registration-free COM ..."
That is some serious nit-picking, there!
I suggest you contact Microsoft straight away and summon them to stop using the wrong terminology for their own techniques:
https://www.google.nl/search?q="registration+free"+"COM+component"+site:microsoft.com


... , which is done by creating a separate manifest file for the dll, and modifying the exe's manifest. That's what we do for textpipeengine.dll (create a manifest "textpipeengine.dll.manifest" using the tlb file).
Already knew that, but thanks for explaining.


The only reason textpipeengine.dll has to be registered now (it was never needed in the past) is because of programming errors in the current version(s?) of TPIPE.exe. That's why replacing TPIPE.exe with an older version "repairs" it: now TPIPE can be run *without registering the DLL*.
No.
.. Followed by an explanation that actually proved my point, as:
The TPIPE source hasn't been changed in months.
combined with:
exposed a bug in the manifest tool...
lead to:
programming errors in the current version(s?) of TPIPE.exe.

It is very clear that the manifest in TPIPE.exe addresses the wrong GUIDs, so it would never be able to "talk" to textpipeengine.dll.
Without further investigation I assumed that it was "linked" (on advice of the nit-pick prevention team this has been placed in double quotes) to the wrong (version of the) DLL. But a bug in the manifest tool could explain that too, I guess ..

The fall-back scenario (registering the DLL) involves addressing the AppIDs (/ProgIDs) instead of their GUIDs, which makes versioning a lot harder (as you said: conflicts with other textpipeengin.dll's)
Just as an older version of TPIPE.exe addresses the right GUIDs in it's manifest and would make things work again.

Now I wonder how things are tested before release ... (this is a rhetorical question)


Installers always run elevated (that's built into Windows). ...
Not very relevant, but also not true.
It is a combination of the settings used by the author of the MSI-script and what is actually needed.
It would take me a minute to create a simple MSI that can be run under a restricted user account, without causing the installer to elevate.

But as I said, registering the dll during installation caused numerous (as in hundreds) of complaints from users running on corporate networks, due to Windows Policy settings.
I'm not able to check now (or the next couple of days), but I'm familiar enough with GPO's to say that there is no such policy.
And I loved to be proved wrong on that (I actually like being wrong; it's a quick way to learn new things)



Currently, about 87% of TCMD users are corporate users.
I'm ... surprised. Better not let those people talk to me, then (or anyone else doing the same job).
 
Last edited:

Similar threads

Back
Top