|
check the windows event logs, all of them.
there could be a number of issues going on here, my initial reaction is that there is a .dll or two, or three that are needed and no longer can be found. If they are swallowing errors in the app, then you will only see this in the event logs...hopefully.
Start there.
Might want to see if you can track down the "creator" of this mysterious and magical custom program, and see what they have to say.
good luck.
|
|
|
|
|
Slacker007 wrote: check the windows event logs, all of them.
there could be a number of issues going on here, my initial reaction is that there is a .dll or two, or three that are needed and no longer can be found. If they are swallowing errors in the app, then you will only see this in the event logs...hopefully.
Thanks hopefully that won't be needed but probably will.
Slacker007 wrote: Might want to see if you can track down the "creator" of this mysterious and magical custom program, and see what they have to say.
As mentioned in one of my other relies, they have his phone number and he's refusing to take ny part in the program at all any more.
Michael Martin
Australia
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible."
- Mr.Prakash One Fine Saturday. 24/04/2004
|
|
|
|
|
Michael Martin wrote: it would dump 2 files to the Desktop
Which desktop? There are two "desktop" folders - the one in the user profile, and the shared one that's usually in C:\Users\Public\Desktop.
Of course, if the application is old enough, it might just assume the desktop folder is in a fixed location, and write the files somewhere completely different.
If you can get access to the machine, maybe Process Monitor[^] might help to identify the problem.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Richard Deeming wrote: Which desktop? There are two "desktop" folders - the one in the user profile, and the shared one that's usually in C:\Users\Public\Desktop.
Shouldn't matter which as they both display on the current users Desktop. Plus I reckon this may have been written around the time of Vista so though it may have existed the Public\Desktop wasn't targetted.
Richard Deeming wrote: Of course, if the application is old enough, it might just assume the desktop folder is in a fixed location, and write the files somewhere completely different.
That's what I believe C:\Users\<username>\AppData\Local\VirtualStore is for. Have another old customer that has bucket loads of data in a Palm III database. I installed that software and to get to the data you have to get in to C:\Users\<username>\AppData\Local\VirtualStore\Program Folder (x86)\Palm\...
Richard Deeming wrote: If you can get access to the machine, maybe Process Monitor[^] might help to identify the problem.
I couldn't be paid enough to start wading through that murky pile of sh*t.
Michael Martin
Australia
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible."
- Mr.Prakash One Fine Saturday. 24/04/2004
|
|
|
|
|
Michael Martin wrote: That's what I believe C:\Users\<username>\AppData\Local\VirtualStore is for.
That only works if the application doesn't have a manifest. If it was written for Vista, isn't running elevated, and doesn't have permission to write to the folder, it'll just get an "access denied" error.
For the purposes of this virtualization, Windows Vista treats a process as legacy if it’s 32-bit (versus 64-bit), is not running with administrative rights, and does not have a manifest file indicating that it was written for Windows Vista.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Use Process Monitor to find out where the application is (presumably) trying (and failing) to write to.
If you've never used it before it's got a really steep learning curve, and depending on how active the software is you might benefit from creating a HelloFileSystem test app to help figure out how to set your filters, but it's a really useful tool for snooping on what an application is trying to do behind the scenes.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Dan Neely wrote: Use Process Monitor to find out where the application is (presumably) trying (and failing) to write to.
If you've never used it before it's got a really steep learning curve, and depending on how active the software is you might benefit from creating a HelloFileSystem test app to help figure out how to set your filters, but it's a really useful tool for snooping on what an application is trying to do behind the scenes.
I'm not that invested in this by a long shot. I'll invest in a carton of beer instead.
Michael Martin
Australia
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible."
- Mr.Prakash One Fine Saturday. 24/04/2004
|
|
|
|
|
Sorry if this has been answered below, I didn't read them all, but get the search program 'Everything'. Run the program to produce the files, then search using Everything but just sort by date and find the newest files. If they exist anywhere, everything should find.
HTH.
Jack of all trades, master of none, though often times better than master of one.
|
|
|
|
|
Ron Nicholson wrote: Sorry if this has been answered below, I didn't read them all, but get the search program 'Everything'. Run the program to produce the files, then search using Everything but just sort by date and find the newest files. If they exist anywhere, everything should find.
HTH.
Thanks. I will look into this tool tomorrow (little more than 30 minutes away) even if I don't use it for the task mentioned.
You should look at posting about this in the Free Tools Discussion Boards[^].
Michael Martin
Australia
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible."
- Mr.Prakash One Fine Saturday. 24/04/2004
|
|
|
|
|
LOL. I've to read all the replies before responding. 
|
|
|
|
|
Insert gratuitous self-promotion here... 
I wrote a program which will watch all files on your disk. I wrote it up here on CP.
1. Fire up the program.
2. Point it at her C:\ drive and have her start the label maker.
3. You will see every file created. (uses filesystemwatcher and is quite robust)
Win10 : Examination of Disk Utilization (Includes DiscoFiles utility)[^]
I even included a zip on that article that contains the pre-built app so you can try it quickly.
It's just one .NET exe.
EDIT
I've seen this type of problem before which is related to the rights the process has (starting under Vista / Win7) to write files only in certain locations. %programdata%, etc. Anyways, from what I remember, the OS will simply block the creation of the files (which are written in improper places) without crashing the program or anything. The files just never appear. This is all related to when MS made those changes about not allowing a process to create a file (even configuration) in the Program Files directory.
|
|
|
|
|
If you knew the name of those files that were supposed to be created, you could install a filesystem indexer like Void Tools Everything[^] and perform a quick search.
|
|
|
|
|
From and old programmer with experiences of old bar code printers a lot did not have Windows printer drivers and needed special coding to produce their labels while other did have printer drivers that I would expect you will need to install and even then they might need the correct bar code font installed before they can print labels with bar codes.
|
|
|
|
|
Maybe the software is set up to print to file, and the desktop was under C:\Documents and settings\... under XP and now it is c:\users\.... and the software simply can not create the file at all.
Same could be the case if the Windows printer was set up to print to file.
|
|
|
|
|
Windows 10 does user names differently to older operating systems e.g. Windows 7. My desktop is stored at C:\Users\benab\Desktop on Windows 10 and C:\Users\Ben\Desktop on Windows 7. If the programmer was using her user name to store it to the desktop (terrible programming practise!), then that would explain it 
|
|
|
|
|
|
A few years ago I had a similar problem. The program I was using, try to write something to a specific path. Because it had an error trap, it never showed an error in which I could find the path. I tried almost everything. No. it didn't work.
Finally I used a Hexadecimal editor (I don't remember which one) to look inside the guts. Almost everything is gibberish, but the strings appears bright as a full-moon light. And Voila! the path showed itself hidden inside «─í▀≈┌▀▐C:\Freemont\Data\Packs.dat▌┌░≈Σ
Because I didn't change anything to the program, when I closed the Editor and created the Folder, all work as desired.
|
|
|
|
|
I agree with this approach. You might try to: 1) make sure the Desktop is not read-only, and 2) make sure the prior version Windows Desktop path exists (thru Documents and Settings, or whatever).
|
|
|
|
|
What kind of barcode printer is it? If it's a Dymo, you may need to install their dev software.
|
|
|
|
|
I have found often with this type of behavior going from an old OS to Windows 10, problem is often related to security. Even running as Administrator does not always give you access to write. In the past creating the destination folder and adding explicit permissions to the account to have full control and turning off inheritance makes a difference. Given the age of the code there may be missing com objects or DLLs that are no longer part of the Windows 10 OS. These problems are a bear to resolve but with the correct tools you'll learn what's generating the error.
|
|
|
|
|
It sounds as if you are dealing with two separate products: a custom "line of business" program written by someone who no longer wants to support it, and a packaged barcode/label making program. Or is it just multiple custom programs that form the "line of business"?
It sounds like the label product installed, but did not create two desktop icons see was expecting to see. It is a bit vague on exactly when the two files are supposed to be created: is it after the software is installed or is one part of the "line of business" software generating those two files which she clicks on and the label software is supposed to utilize?
It is just a slow and steady process to determine her problem, and you indeed might end up with "sorry, there is no solution." How important is this client? Can you skip a lot of the determination work and just get to "sorry" earlier?
|
|
|
|
|
Old programs work better if NOT installed under C:\Program Files (x86).
|
|
|
|
|
Found this that may be fairly easy to figure out what it's trying to create.
There are other solutions too for tracing file access.
It's may be failing the file creation as it's using a on-existent path and hopefully this software sees the failure.
https://www.visualclick.com/content/cptrax-for-windows-active-directory.htm
Or process monitor should do it too
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
You can run it directly from the site if you want
http://live.sysinternals.com/Procmon.exe
Mike
|
|
|
|
|
For "app data", the usual convention is:
c:\ProgramData\<company>\<app data="">
(i.e. "Users" is not the only place where app data gets stored; including the "exe folder").
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
I would run the program in a VM of Windows 7, and use the old SysInternal Tools to identify the file creation.
I have had THESE kinds of problems when going to Windows 8 and Windows 10 from very old code that writes stuff to it's own PROGRAMS folders... ALL due to security differences.
Windows DOES NOT want things written "anywhere", data goes in appdata, etc.
And running as Admin does not always fix stuff, because the resulting EXPLORER instance is NOT in admin mode, so it may not see the files created.
That is the FINAL nail in the coffin. If it is using ANY KIND of share, KNOW THIS: A share created with an ADMIN account is NOT accessible to the USER account, AND VICE VERSA. This crushed us recently on a VM setup where the developer runs as admin, but the use program cannot. AND BAM, the share can only be accessible by one at a time, until you tweak the registry!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
