Everytime I start up my laptop, I get the following error:
Can't find file C:\Users\robert\AppData\Roaming\Microsoft\Windows\dhisevfi\eieteifb.exe Check if you have the entered the name correctly and try again after.
I can't find this .exe file anywhere on my laptop and even on the internet it can not be found. Check here to see the image of the error.
StackOverflow is my last resort to solve this problem since no one seems to understand why it happens.
I would be very grateful if someone could me out a bit further.
Thanks in advance!
Robert
I've just searched the internet and I didn't find the name of this executable, which most likely means that it has been generated automatically, which is a typical situation for ... a virus! (I had a similar situation several years ago)
So, apparently your computer has been infected with a virus, the corresponding executable is not (longer) present on your computer, but your computer (still) wants to launch it. (Don't worry: as the executable is not there anymore, there won't be any harm to your computer anymore)
I'd advise you to remove this entry from your startup folder, but this action depends on your Windows version. There are lots of entries about this subject all over the internet.
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.
When I try to load a form in the designer, it shows "runtime error 0" and produces a log file which contains:
Line 15: Cannot load control xxxx; license not found.
But the control in question DOES NOT have any licensing restrictions. It has no installer and requires only registration (regsvr32).
Not only that, but for years this had worked without any problems and only just recently this has started. It affects a number of forms which have any controls from a particular OCX.
So it appears that something is fooling VB6 into either thinking a license check has failed, or at least to show a nonsensical error message.
I have tried to trace this using Process Monitor but I couldn't spot any useful clues in the logs. At least, nothing which was obviously problematic.
Any ideas what could cause this? I'm at a loss so far to find a cause.
Thanks
I'm assuming this is a third-party OCX... Many such products came with their own installer which generates the license file; simply copying, and even regsvr32ing the .ocx is not sufficient to use it in the development environment. If you still have the original installation routine, you can try running that to regenerate the license. Failing that, you could look for an appropriately-named .lic file on an existing, working development machine (in \Windows\System32, or the VB6 installation directory, or in the directory into which the .ocx is installed) and manually copy that to the same place on the new development machine.
(Answering my own question, should anyone else run into this again).
As far as I can determine this error was caused by either a subtly corrupt FRX file and/or an FRM/FRX file pair being out of sync.
By going back in source control I could eventually locate a revision where there was no problem. This alone seemed to eliminate anything in the computing environment from being the cause. (ie, bad VB6 installation, disk space, etc. etc.)
I manually re-did certain changes and brought that older code back up to date, and so far the problem has not reappeared.
EDIT the struck-out text was not incorrect but was not specific enough -- I have since learned what seems to be the root cause.
The problem was that we loaded a 32-bit ICO file (icon) into an imagelist in one of the VB6 forms. Now, traditionally 32-bit color icons were not usable in VB6 and you would get an error even trying to do this. However for some reason certain Windows PCs will now allow this - which can be a time bomb.
The problem is: forms saved that way can cause the errors in this question when run on a different PC which does NOT support such icons.
This will occur in the IDE when the form is loaded, OR if a compiled EXE is run on a different computer which respects the original VB6 icon limitations!
I don't know why the totally meaningless "licensing" error message is shown when this happens.
In my case we didn't intentionally introduce this icon, it was a mistake, and so it took a LONG time to debug and eventually figure this out (plus some very valuable advice from people on VBForums).
I've created a different question specifically to try and get at what underlying element of Windows has changed causing this problem.
As far as I can detect all machines are the same that excelDna is being used on.
On one specific machine I tried to use the code I have created, and ran into an issue. Logically I thought this was odd and instead tried to add a sample file that comes with the download.
So now, I am trying Errors.xll/Errors.dna that come as a sample. The same error occurrs. Therefore to me there is an issue on this specific machine.
The error I am receiving is "a problem occurred while an add-in was being initialized (InitialIntegration failed). The add-in is built with ExcelDna and is being loaded from P:\xlDna\Distribution\Errors.xll"
Has anyone encountered this? Help needed to understand why this is happening as it seems quite opaque to debug.
Hi what solved this for me was moving the xll and DNA to the users c:. Once located on the c: worked flawlessly.
Hope this helps someone else in the future.
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.
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.