There is an external application which we get from our external suppliers, lets say the executable is a file named "SomeApplication.exe".
In a past version of this application, when it was started and I was looking in Taskmanager->Processes, I saw it appearing in 8.3 format with the name "SOMEAP~1.EXE".
Now we got a newer version, and in this one, in Taskmanager it is displayed normally as "SomeApplication.exe", exactly like the file name and as I would expect it.
To make it clear again: Same filename, one time process name appears in long format, one time on 8.3.
Can someone explain this behavior to me? Is it somehow controllable from implementation-side or OS-side how the process name appears?
PS: OS is always Windows Server 2008 R2 64Bit.
Related
I installed ghostscript on windows and added it to path variable but I'm still getting
gs is not recognizes as internal or external command
I tried to run the .exe file to check the installation and it says
This software us supplied under the GNU AGPLv3 and comes with NO WARRANTY: see the file COPYING for details.
Unrecoverable error: invalidfileaccess in .addcontrolpath
Close this window with the close button on the title bar or the system menu.
On Windows the Ghostscript executable is not called 'gs', it's called one of gswin32/gswin32c/gswin64/gswin64c, depending on whether you are using the 32 or 64-bit version and the command line or windowed executable.
So the error message doesn't make a lot of sense, unless it's coming from some other application. In which case you are presumably running something written for, or ported from, Linux. Or, of course, you are trying to run it from the shell by executing 'gs' when you should be using the actual executable name. If that's the case, try using the correct name.
More puzzling still is that the title of this question doesn't appear anywhere in your question body. You don't mention an invalidfileaccess, nor do you quote the back channel from Ghostscript which would give some clue what you are doing.
We really need to know more about what you are doing that doesn't work.
I have a program that extracts text from PDFs. It runs as a scheduled task on Windows Server 2008.
The library I use is ByteScout's PDF Extractor SDK, which is based on Tesseract under the covers.
Since it went live last November, the program has successfully extracted text from over 50,000 PDFs from many different sources.
It recently hung on a single PDF and subsequently on a second one, from the same source in the same visual format.
I am able to recreate the problem using a trivial 12 line program. I sent this program to the vendor but running that program in their environment works (it does not hang).
So I did some experimentation and this is where it gets strange.
The program works on my PC (Windows 7) if I RDP to it, but not if I am directly logged in. This behavior is repeated on other Windows 7 PCs in our environment.
It works on Server 2008 if I am RDPed, but not as a scheduled task.
It works on Windows 10, whether I am RDPed or logged in directly.
If I watch the program in Process Monitor when it is stuck, I can see that it is opening and reading C:\Windows\Fonts\times.ttf over and over again.
If it was only working using RDP, I'd wonder if the cause had anything to do with failing use of graphics acceleration or some such, but given that it doesn't work as a scheduled task where none would be present either, I think that's a blind alley.
Does anyone have any suggestions where to look next?
So ByteScout have fixed the problem. To quote Eugene on the cause ...
The problem is in System.Drawing and GDI+. Sometimes it crashes on text drawing operations that are normal in PDF but causing some internal exceptions in System.Drawing. Moreover, it's behavior varies depending on display device capabilities. That is why it works in RDP session and crashes on a desktop.
We are trying various workarounds on these crashes, attempting to fall back to alternate text drawing ways. The hanging is related to these fallbacks.
I received a windows application that is create a file on my windows. How can I find out where the file is?
I guess the program create a text file to save a code or something. I want that file. What can I do and how can I find it?
Sorry for bad English.
You can use Process Monitor to monitor any changes to file system or registry a program makes. Filter for the name of your programs executable and for file creation. Then run your program and analyze the log. Be prepared there might be a lot of entries.
Also keep in mind that "codes" are often not just stored in files. It might be in the registry and it might not be in the format you expect...
I've asked the very same question here :
Why does my program say "folder does not exist" when run on Windows 2008?
but none of the answers were satisfying and my problem still exists , so I decide to ask it in another way with more detail cause this problem really irritate me and we need to solve this , otherwise we have to write the similar application in another language which means waste of our time.
program written in delphi 7(32 bit)
environment running this program is : windows 2008 r2 64-bit
the task program try to do : creating 3 folders then copy an sound file and compress it using lame commmand line (lame.exe) and save changes into database
error I get : "THE 'folder' does not exist . the file might have been moved or deleted , Do you want to create it?" and it cause the program become halted
things I have done :
1- try to run the program as an administrator
2- check eventlog but no clue
3- triple check the required folder and all of them was correct
4- read this KB: http://support.microsoft.com/kb/927387
BUT still I am seeing this bloody error.
I have uploaded the picture of the error here as you see it clearly :
http://i28.tinypic.com/9to6qr.jpg
The folder name is C:\Upload_ABC\\2010\07\27\:
please notice I haven't written that unwanted dialog-box inside my program I believe windows 2008 attach it or bring it on my application.
please please please give me some idea or let me know what should I do ?
best regards.
C:\Upload_ABC\\2010\07\27\
You have two backslashes in your path. Use debugger to see why.
Have you checked the access rights for that folder structure with regard to the account the Delphi program is running from? Windows Server systems tend to be more restrictive in what a user is allowed to do than Windows on workstations are.
In addition I suggest to strip down a copy of the program to the relevant functionality to show the error. With this you get at least a chance that anyone around may test it on another system.
Furthermore you can try to compile it with D2010 and see wether the error persists. If it does, you might have a chance to find the problem running the D2010 debugger. If you don't have D2010 at hand, you might install the trial just for this purpose.
What is between the two consecutive backslashes in your path? Is there really nothing between them or have some characters been removed because they are Unicode and D7 doesn't support Unicode?
As there is nothing in between the two consecutive backslashes...
It does sound like Windows is getting its grubby little fingers in between your program and your access of the files. Either the folders have not been created, or you are being denied access once they have. And as the changes you are trying to store in your database involve compressed files, virtualization seems to be the culprit as explained by the link you yourself provided.
A couple of avenues to try:
Remove any compatibility settings on your exe (right click|properties|Compatibility tab) that could trigger Windows to butt in. Also don't forget this can be triggered by things like "setup" or "update" as part of the executable name.
"Save your application's data in a folder under your user profile."
Such as c:\users\\documents or some such (better not hardcode it in actual production code, but ok for debugging). That after all is exactly the advice the linked msdn article is giving for scenario 2 "you cannot find the files or folders you just created"
If you can't debug on the machine where it is running, go back to old school debugging: add trace messages to your code to show where in the code you are (and have been) and show them in a memo on a separate form or some such.
Make sure you don't "eat" any exceptions that could give you extra information about what is going on.
I have a VB6 desktop application that is deployed on well over 1200 desktops. The devices throughout are a mix of Windows XP SP2 and SP3 systems. All but one of these PCs (XP SP2) is able to successfully decipher the DOS 8.3 path (ie C:\PROGRA~1\DATFOL~1\Config\) that is used in an .ini file related to this application. This particular PC errors out with a message: "Run-time error '76': Path not found".
The string is obtained from the .ini file using the
GetPrivateProfileString function. (The string is not hard-coded into the application - it is obtained from an ini file).
Since there is only one machine having the problem, I'm looking towards some configuration value on that device as being the root cause. I looked at the NtfsDisable8dot3NameCreation setting in the registry to see if this might cause the issue, but I have been unable to reproduce the problem on any other machine when changing this setting.
Anybody have any thoughts or perhaps another direction I could take?
Don't use hard-coded paths or short filenames. The Program Files folder might not be on the C: drive, might not be named Program Files, and even if it is, might not have a short filename of PROGRA~1 (and the same for DATAFOL~1). Write the install path to an INI file or the registry during installation and read+use that in your program.
If someone was gimping around and made a temp/backup/testing \DataFolder_Temp, deleted the original then renamed, the short path would be DATAFOL~2.
Delete the directory and recreate it.
check the PC. The PROGRA~1 or DATFOL~1 might actually be ~2 instead. Put the 8.3 name used in your code into explorer and see what IT tells you.