|
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!
|
|
|
|
|
Get a copy of ProcessExplorer from sysinternals.com. It's free:
Process Explorer - Windows Sysinternals | Microsoft Docs[^]
This program is extremely handy--it will show you every file that is being created/read/etc, along with what registry keys are being read/added/etc. The log files get huge fast, but for a tricky job like this it will be worth its weight in gold. It's helped me track down really weird/obscure stuff like this.
|
|
|
|
|
I'd upvote every suggestion that the program is trying to write files in a now restricted space. There are so many butts running around with chunks taken out of them by this security change, mine being one of them. It's an easy change if you have the source code - muahahaha - don't comment on that. As a consultant, I'd say sorry, your code is obsolete, here are some options and here's what it will cost you. Let me know if I can help.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Dunno if someone mentioned that already, but Process Monitor is a fantastic tool and is well-suit for exactly this use case.
|
|
|
|
|
Spot a clue in unusual theory (11)
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Hmmmm... maybe attempting these everyday is finally starting to pay off!
Speculation = theory
Anagram of Spot a clue in
|
|
|
|
|
Well done - you are up tomorrow! 
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
|
Finally! A decent replacement for Javascript! 
Latest Article - A Concise Overview of Threads
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Well, the BASIC interpreter is implemented in js.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
