Our software posts errors to an online database when users encounter errors. In reviewing the database we noticed that ::DeleteFile() occasionally fails with ERROR_ACCESS_DENIED, but only when the user is running a non-English version of Windows. Yes, strange but true! We have never had this error posted except with non-English error messages. The messages span human languages, e.g., "Toegang geweigerd," "Zugriff verweigert," "Accès refusé," "Acceso denegado," "Åtkomst nekad," "Ingen tilgang," "Käyttö estetty." etc. Never in English. Strange!
More Info: We've had these messages posted for ~40 users, we have ~3000 users, and ~80% of our customers use English versions of Windows. When it does happen to a customer, it appears to happen repeatedly (e.g., each time they use the software). The name of the file being deleted is the same regardless of the human language (i.e., the name is similar to "setup.exe"). It doesn't seem possible that the language could be coincidental.
Do you have any ideas on why DeleteFile() would occasionally return accessed denied on non-English version of Windows?
Related
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.
I need some "light" to get a solution. Probably there are tons of things that cause this problem, but maybe somebody could help me.
Scenario: a Windows server running 24/7 a PostgreSQL database and others server applications (for processing tasks on database, etc...). There are differents servers scenarios (~30), with different hardware and windows versions (XP SP3/ WinServer, etc... all NT based). All aplications were written in Delphi7, and link to DLLs (in D7 also).
After some days (sometimes a week, sometimes a couple of months), Windows begins to act strange, like not opening start menu, some buttons are missing in dialogs. And soon some applications do not open, raising a event on eventviewer:
Faulting application x, version y, faulting module kernel32.dll, version 5.1.2600.5781, fault address 0x00012afb
In mean while, others applications open fine, like notepad, iexplore, etc... but SOME of my applications don't, with only event log described above. But if we do not restart system, in a few days even cmd.exe stops open, (and all other applications) with same error on eventlog.
I've tried to find 'what' can cause this, but with no sucess. So, and any advice will be welcome.
Thanks in advance.
I think you are running out of resource handles (Window handles). You can verify this by having a look at the system properties in Sysinternals Process Explorer (a better task manager). I think even the default task manager can help out to display a handle count. Then you can identify which application is causing the trouble.
Once you know the application leaking and if it is yours, you can use Rational purify or Boundschecker to drill down to the problem. If you do not have money for these tools you will have to reduce the problem manually a bit by deactivating some features for example and see if the handle count still increases...
Not sure if it is the problem you are experiencing maybe it is completely unrelated. But easy to check. The track is that some app is stealing some global resources as you experience trouble with other applications. Applications like notepad do not use much resources so appear to work fine, heavy apps are more likely to show up the trouble.
Hope it helps.
For my work, I need to create a service that will detect an abnormal program termination and, instead of displaying a message to the user (default behavior), send the generated core dump to a remote server.
I'm pretty sure this can be done, but I have absolutely no clue on where to start. Is there any API/registry settings for this ?
Thank you.
One method is to install an Unhandled Exception Filter and then write a minidump from it which you can then upload to some place of your choosing. I wouldn't totally disregard Windows Error Reporting -- that's an addition to any crash reporting of your own. If your application is for public release then registering for Windows Error Reporting is well worthwhile as you get information about which crashes users are encountering in the wild and when crashes have been fixed you can add a response code to point them to a new version or other relevant information.
Another tool that may be useful depending on how your application is deployed in your organisation is to run Adplus on a user's machine which will collect together crash dumps. This is more useful for one-off crashes that seem to affect an individual user but aren't reproducible in a development environment.
Some other useful links:
http://www.debuginfo.com/articles/effminidumps.html - some useful sample code
http://www.codeproject.com/KB/debug/postmortemdebug_standalone1.aspx
It seems my question was either obvious or stupid (both ?) but anyway, i found some interesting pages after some researches.
Here are the links I found useful:
Track application crashes and disable Windows Error Reporting at the same time!
Disable error reporting
We've been plagued for several years by occasional reports from customers about a non-descript error message "Cannot set allocations" that appears on startup of our app. We have never been able to reproduce the problem in our own test environments so far. I have now run out of ideas for attempting to track this down. Here's a collection of observations that have accumulated over time:
Error message text reads "Cannot set allocations" (note absence of punctuation).
The window title simply reads "Error" (or the localized equivalent).
The "Cannot set allocations" text is always in English regardless of OS locale.
I have so far not been able to locate the DLL or EXE containing the message text.
Google is chock full of reports of this error for a variety of different products - but no solutions.
The only unifying aspect between the affected products I could make out so far was that they all appear to come in the form of DLLs that load into third-party processes (such as addins for Visual Studio or Windows Explorer shell extensions).
Our app is actually a shareware COM-addin for MS Outlook, written in Delphi (i.e. native code - no .NET).
The prime suspect in our case is the third-party licensing wrapper that we're using which decrypts and uncompresses our DLL into memory on the fly. Obviously I couldn't simply give an unprotected version of our app to the affected customers to verify this suspicion. Maybe the other vendors that this has been reported against are using similar products.
Debug versions of the protection wrapper supplied to us by the licensing vendor yielded no results: The log files looked exactly the same as from sessions where the error did not occur. Apparently the "inner" DLL gets decrypted and uncompressed all right but for some reason still fails to get loaded by the host process.
By creating an unprotected "loader" DLL we have been able to pinpoint the occurrence of the error somewhere behind the LoadLibrary call that is supposed to load our DLL into memory.
Extensive logging and global exception hooks in our own code (both the unprotected loader and the protected "core"-DLL) yielded no results at all. The error is obviously raised somewhere else.
The problem described in this earlier question of mine was very probably prompted by the same issue. This was before we created the unprotected loader stub.
The error only occurs at about 1-2% of our customers - whereas typically all installations at any affected customer's site are affected the same.
Sometimes the error goes away after we release a new version but often it will come back again after a couple of weeks or months.
Once the error has started to occur on a machine it does so consistently.
The error never occurs while connected to the affected machine via remote access (e.g. VNC, RDP, TeamViewer, etc.) and none of the affected customers are within travel distance from us so all we have to go by is log files and "eye-witness reports".
One customer reported that the error message dialog apparently was non-modal, i.e. he was able to simply move the dialog box to the side and continue working with the application (minus the functionality that our DLL would have provided). Not sure whether this is universally true in all other occurrences, too.
In some cases customers have been able to permanently rid themselves of the error by disabling or uninstalling other addins from other vendors that were sharing the host application with our own product.
The error has so far been observed on Windows XP, Vista and 7.
During the last few weeks we had a surge of reports from Outlook 2003 / Windows 7 users. Could the situation have been made worse by a recent Windows/Office-update?
Does anyone have any experience with this error at all?
Or any more ideas for investigating this?
I have only recently had this happen, which prompted my search and I ended up here. I can tell you that with me for sure it is in windows 7 home premium BUT ONLY WITH IE9 (which I hate by the way) it reduces the user back to the dummy stage and assumes that we have to be repeated flagged about everything.It will keep asking you if you want to disable add ons to speed up load times but usually on things that aren't really the things slowing the browser down in the first place,it is there is too much garbage loading in the first place.But back to the "Cannot set allocations", I for one have never expirianced it in any other browser which is not to say it doesn't happen with them.
This is going to be pure guess-work, but it sounds like maybe your third-party licensing software is trying to load your DLL at a particular location in memory, which - on these failing systems - happens to already be occupied by something else, perhaps a global hook DLL.
If you have a customer who is willing to work with you a bit, it might shed some light on the situation to get a crash dump (e.g., with ADPlus or maybe simpler with Sysinternals' ProcDump) when the error message is showing. That would show what modules are loaded and possibly the callstack (if it is from a message box at the time of the error as opposed to one that is catching an exception after the problem).
I also have experienced the "Cannot set allocations" issue. Royal pain. I had disabled Java, since I did not seem to need it, I used add/remove programs to remove Java from my system. Then I stated to get those errors. I have reinstalled, but disabled Java in IE explorer. Now I do not get the error anymore. Not a programmer, don't know why this happened. Maybe a clue for someone.
Win 7 - 64bit OS IE Explorer 10. Hope this helps someone figure this out. John
I've seen this happen. In my case a global hook dll created a large memory file mapping, perhaps to the memory the licensing dll was counting on.
I see "Cannot set Allocations" when I open google chrome only. Also after that, chrome closes with a msg saying "Whoa chrome has crashed..."
Still no solution :(
Also not a programmer, but it always happens when I open Chrome. It opens second window with error message 'cannot set allocation'. I usually close it and go on my way. if i don't it usually causes a crash. doesnt happen on any other browsers.
I'm stuck trying to debug a problem which only occurs on my machine. It doesn't exhibit on any of the other devs' systems, nor on our production test server. I've tried pretty much everything I can think of short of completely wiping my hard disk and starting from scratch, or sneaking into the office in the middle of the night to swap my computer with someone else's.
This brings to mind the titular question, then: short of those drastic measures, what do you do when trying to resolve issues that no one else has? I'm open to advice that's general or specific.
[Not sure if this should be CW or not.]
Have you attached a debugger to the program to find the exact point of failure? That is what I would do first.
Sometimes third party software can be the root cause of these sorts of issues. Things like Anti-virus software install low-level filesystem and network drivers that can cause random intermittent failures. You can try killing all processes that aren't base OS services and your app.
Depending on your OS there are different tools that you can use to see what's going on under the covers. E.g. on Windows you can use Process Monitor to see what Registry keys it opens, what DLLs get loaded, etc. You can run this on your machine and on the success machines and compare to see if perhaps some required module is missing .
But seriously, use a debugger. That's what they are there for.
Two things:
I start with the obvious: What's different on your box? More memory? Odball PCI card? Different Microsoft APIs or service packs?
For oddball random software and/or OS crashes:
Check your system for heat issues.
Check your RAM for bad bits.
In this situation, I would try to check out the code and cleanly rebuild it from a different directory to make sure that there are no miscellaneous files in your working directory that are causing a problem.
If you are doing work against a database, I would also try tearing down the database and reconstructing it, possibly using a dump from another developer's machine.
Check the versions of any external third party software - database version, OS version, even software patches.
Look at the configuration on someone else's machine who doesn't have the problem and compare.
Get another developer to sit at your workstation and try to reproduce the problem and also go to their workstation and try it. True story - a fellow developer had a bug that he could only reproduce on his machine...it turns out that he was doing something slightly different in the GUI that no one else was doing (tabbing to a button and then hitting enter, everyone else just hit enter). It never occurred to him that other people might just hit enter to submit, because that "didn't make sense" to him.