It looks like some executables do not shut down correctly on Windows. After stopping the application, and deleting the corresponding exe file, it immediately pops up again in the folder. I have to wait for some time (sometimes even minutes) until I can really remove it. Is there any reason/solution for this strange behavior?
This is very annoying, because I'm creating a release directory with a batch script, which previously removes the release directory in case it already exists.
I finally found the reason, thanks to this post:
https://superuser.com/questions/338567/why-cant-i-delete-some-exe-files/521349#521349
For some really really crazy (Microsoft internal) reasons you must have the "Application Experience service" enabled!!! God knows why! On German installations the service is called "Anwendungserfahrung". On my machine it was disabled. As soon as I enabled it, I was able to delete executable files immediately after terminating the EXE/programm!
I hope this post prevents others from going crazy like I did! ;-)
Related
the other day my little brother downloaded a game from somewhere, and as I caught him in the act of installing it, I noticed a little pop-up window in, like old windows graphics, popped up all sneaky and said "be now on auto start" or something close to that. So, is there any way I can find out what that was, where it is, or what it's doing, so I can see if it's a virus? thanks for your time and effort. the spell checker wont let me type v before "be on auto start"
There is no surefire way to locate an unknown .vbe file that is currently running. However, some detective work may be able to uncover its location. Try checking recently accessed files, running processes, and open network connections to see if any clues can be found.
I have a VB6 application that I provide support for. This application works on both Windows XP and Windows 7. Some users were migrated from Windows XP to Windows 7 using the User State Migration tool. These users now receive a generic "Application has crashed" Windows error message when they open certain screens (forms) in the application. My assumption is that there is a missing dll/ocx reference, but I'm having trouble tracking it down.
I've tried many/varied troubleshooting techniques:
Full uninstall and reinstall of my application
Manually re-registering all dll's and ocx's that I know are used
Running Process Monitor on a broken computer and a working computer to compare what dll's and ocx's are accessed. The answer might be here but even after filtering out most of the background noise the amount of data is overwhelming. At a minimum I reviewed all of the calls right before it crashes and all of the calls that were not successful. All of the non-successful calls match between working and non-working.
Installed the Windows Debugger Tools and captured a crash dump. Analyzed the crash dump with DebugDiag. DebugDiag says the exception is in msvbvm60.dll. I tried building a PDB file for my exe and loading it in DebugDiag to get more detail about where the exception is occuring but DebugDiag doesn't want to accept the PDB (might be doing something wrong here, but it just seems to ignore it. This same PDB file works fine when I do remote debugging, however.)
I recompiled my VB6 program without any optimizations in PCode. I've read online that sometimes building in PCode, while bad for performance, will tell you the real exception.
Used the above created PDB file to remote debug the VB6 application. The debugger says that the application crashes after the new window has been created, on a line that sets MousePointer = vbHourGlass... To me it seems unlikely that this is the real cause of the error. There are at least 20 other locations in the program where this same line is called and all work fine.
(Forgot about this one)
Used Dependency Walker and profiled the application on both a working and non-working computer. All errors found by dependency walker were the same between the two computers. There were no additional dependencies found on a working computer, and all missing dependencies on the non-working computer were also missing on the working one.
None of these actions changed my error message or showed me what the error is (unless it really is the mouse cursor issue)... There are no entries in the Windows Event Log related to the app crash.
The non-working and working computers all have the same base Windows 7 image, the only difference is whatever is being changed by USMT, which further convinces me that this is some kind of quirky configuration change or a missing dll/ocx or perhaps an unregistered dll/ocx.
Any ideas or thoughts on how I can track down the root cause of the issue would be greatly appreciated.
Update 1 - Response to questions
#MarkHall I have tried running it as admin, though not with UAC off. The application runs fine on a Windows 7 box as a non-admin with full UAC. Windows XP was 32-bit, Windows 7 is 64-bit, but again it works just fine on a like for like box where the user was not migrated from Windows XP.
#Beaner It's possible that it stores settings somewhere that have been corrupted, but the remote debugging leads me to think that it's more likely something else since it seems to die on a step related to the UI, which then makes me think it's probably a missing dll/ocx reference.
#Bob77 The application is installed into Program Files (x86). While many of the libraries do reside in the same folder, they are all registered.
Peter, often I've noticed that the debugger will indicate a line of code that is actually incorrect, depending on WHERE in the actual assembly language the fault occurs. You should look REAL close around your statement that sets the cursor to vbHourGlass. Your exception is PROBABLY happening BEFORE that line of code, but that line is what the debugger thinks is the actual faulted line of code.
Since you said it happens when a window OPENS, I'd look real close at any ocx's you may have referenced on the form, but perhaps NOT actually being used, or called. You might have one there that you don't intend to be there, that could be causing security issues, or something on Win7? Edit the .frm file by hand if you have to, and look at all the GUIDs the form references.
It is possible that one machine is using PER-USER registration, and the other is using PER-SYSTEM registration?? I don't know...
I would take a much closer look at the form that you are trying to open, and be VERY cautious of everything you are doing in the form load events, and so on. This sounds like it could be something as stupid as Windows Aero being enabled on one system, and not another, or some other sort of "Theme" setting that is throwing the VB Form Rendering routine into a hissyfit... Perhaps even something as stupid as a transparent color index in the icon you selected for that from?
If you are still developing this app, (or at least maintaining it), create an entirely NEW form, and re-create all the controls, etc, on the form (resist the temptation to copy/paste them from the old one...), and then see if THAT does the trick. Then, copy all the event code to the new form one event at a time, with at LEAST enough event code to make the form function, even if it's just a "dead form", that loads no data, or whatever the form is supposed to do. Check and debug after each change, and you WILL find it eventually. Of course, make sure you isolate one of the defunct systems to have a platform that you can duplicate the issue on, or then it's just guessing. I find that using something like Acronis w/ Universal Restore is a great option to then take the image file into a good HV, like VirtualBox, and then restore that image as a VM, so you can debug without interfering with your actual users. This sounds like a lot of work, but then again, so is re-writing an application that already exists, right? :)
Failing THAT... /* and */ are your friends!! (Well, we're dealing with VB, so ' would be your best friend! heh... But I'd start commenting out all the code on the form until that sucker opens. Then once it opens, start putting one line back at a time, and re-running it... That's called "VooDoo Debugging", but sometimes, you gotta do what you gotta do...
THANKS A LOT PETER! :) Now you got ME so involved in this, I feel like I'M the one debugging this sucker! Like if it was MY code I was trying to fix! :)
Let me know if any of this helps... I am actually quite interested in what you discover.
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 some code that is reading a config file, but when I open the file in TextPad, I see different values than my application does. I checked it with Notepad. Notepad agrees with my application, TextPad shows something else.
This is on Vista x64 Business.
Any idea what could be causing this? I've looked in the Context Menu->Properties->Previous Versions details, but it says "There are no previous versions available".
Here's the steps to replicate (I can't make it happen reliably):
Installed .NET app in Program files.
That app reads the config file, but is falling over.
I manually edit that config file in Textpad.
The change doesn't take effect.
I open the config file in Notepad, and see something different.
Try making the change in Notepad and saving, and get this error message:
Notepad
Cannot create the C:\Program Files (x86)\Daniel Schaffer\WorkingOn for FogBugz\FogBugz > WorkingOn.exe.config file.
Make sure that the path and file name are correct.
I can't put the content here as it's XML and is being encoded by Superuser.com, but here's a link to a screencast: http://screencast.com/t/zhERl7mocp4.
Sounds like a case of you don't have administrator privs, when you installed your app. Sometimes when you install an app with no admin privs, it behave really strangely because of vista security model. I had a similar problem to this last year. It wasn't the exactly, but it was strange behaviour, until I figured out it was vista's security model. It elevates it into application/user security context, from what I know, as my brain froze when I was reading about it, as it was pure muck and virtually useless from what I can see.
Try opening Textpad (excellent app) with Run as Administrator, and then edit the config. See what happens. If it stays then same then its a prives problem. If that doesn't work, deinstall you app, and then install it as an administrator. That will give the app the write admin privs to work. Then when you edit the config. See if that works.
Take a look at this. You can elevate an app to run as administrator, Using the techniques found here. How to elevate an application.. Try all these before you do a reinstall.
If that doesn't work, post your question to server fault. Also post it to a suitable MSDN forum.
Hope that help.
Bob.
This is interesting. My guess is that a Vista Feature called UAC Virtualization (aka Data Redirection) is at work here. It basically redirects legacy applications to %USERPROFILE%\AppData\VirtualStore\Program Files\... so they can write files in the program's directory.
Maybe Textpad tries to open the file in read-write mode while both your application and Notepad use it read-only?
You can fire up Process Monitor to see the exact magic, and please let me know ;-)
Try just to strip that whitespace character from application name; my guess is something related to canonical path building
try to copy file to another path and reopen it. see if it changes the result.
One thing you can do is observe what exact file each of those methods ends up opening. To do this,
launch Process Monitor from the sysinternal suite.
look only for file operations (deselect registry operations on the right of the toolbar)
select only your own process (filter out all the processes that you don't care about, or just include your own process name in the filter list)
You can also simply use the search function for your file name, this might be the faster route.
Process monitor has helped me find so many issues it's amazing.
How can I find what's hanging all new installations on a Windows box?
While testing an installation script on Windows (XP Pro, if it matters) I've run into a situation wherein any and all attempts to install anything on the system hang waiting on who knows what. When the system is restarted, all queued up attempts at installation then go through their exit paths with pop-ups that report the installation is being aborted due to system shutdown having been requested. Of course, reboots do not cure the problem. The system otherwise runs fine.
So... How can I determine what part of the OS I've wedged? (Something in the registry, I suppose, but I'm a real greenhorn when it comes to Windows.) Most likely, something from a preceding install attempt went awry and is now blocking even though I saw no errors reported. Once I figure this out, I want to put in a check for this sort of thing, possibly at both ends of my install scripts, if that seems reasonable.
Thanks for your input.
UPDATE:
Unfortunately for me, rebuilding from scratch to get to the point the system's in now is about 9 hours. I'd like to unwedge it from where it is now rather than reload (again). Procmon seems great but I haven't got SP2 installed, only SP1! -frown- So, other ideas are welcome.
I assume you've tried logging the install to see where things go wrong?
Try rolling back to before things went wrong using "System Restore", if that doesn't solve it and the MSI log files show nothing useful then I'd take the plunge and reload before wasting any more time on it.
That said, if you're developing installers then taking an image of this PC in it's crappy state could be a worthwhile exercise. Some point in the future when you have more time to debug you can try and figure out what the problem is.
P.S. I'm assuming you're asking this question from the point of view of someone developing an installer and not as a tech-support question... otherwise this question should probably be closed as not-programming-related ;)
Try using Procmon to figure out where the installer is having problems, if you set a filter it will report all file and registry activity for that process.