I got a problem recently that when I added a code to a lib, which is used by a dll, the dll cannot be loaded. I get an exception "Floating point invalid operation at xxx". When I comment out the code it works. The code added is just straight forward like creating a TADOQuery object, add the sql statment and the parameters, then do an open, check value etc. Nothing suspicious. Now when I uncomment the code and comment another chuck of code in the unit elsewhere, it starts to work. So obviously the newly added code was just tripping the issue caused elsewhere.
Now this error happens when LoadLibrary() call is invoked. There is no attach code. The DllMain, just has a return 1. When this happens the assembly code is always at FSTP tbyte ptr doing a System::Variant::Clear().
Anyone has come across such issues? Any tips on how to debug is also appreciated.
PS: It could also be Embarcadero's compiler issue. I recently figured out that the assembly generated for a combination of assignment and comparison is incorrect. The only suspicion here is the lib that the dll uses is large. When I do a clean and build of the lib, the total lines shows 5.7m. Maybe there is some setting for large libs?
IDE-XE4, c++ builder
OS-Win 7
Thanks,
Mathew Joy
C++Builder and Delphi have different default FPU settings than, say, MSVC and the DLLs written in it.
It probably goes like this: After DllMain, certain exceptions are masked to be hidden. But before the first floating point operation in C++Builder code occurs, that exception is unmasked and the exception occurs.
This is a known problem with C++Builder/Delphi floating point and DLLs.
Related
I have a DirectShow filter (MonogramAAC encoder) successfully compiling. It also registers successfully, however, when I try to instantiate the filter in GrapheditPlus, it shows a CO_E_ERRORINDLL. After inspecting the filter properties under GraphEditPlus, the filter was actually linked to RegSvr32.exe instead of the actual host DLL!
Here's the evidence:
I'm sure the .def file in the linker is correct, I also tested that it IS being considered by the compiler and it is correctly pointing to the filter DLL.
A little bakground info:
I couldn't get the original project to compile under Visual Studio 2017 after automated conversion. (I couldn't resolve strange MFC and runtime library linker errors between the Monogram filter and the libaac.lib library, that I'm also able to compile successfully).
Finally I decided to recreate a brand-new VS2017 Project mimicking the original one and got it to compile and register (with the only warning being the mismatch between the Project name and the output library), but obviously I missed something important while recreating the project.
Any pointers?
Ok, I managed to find the reason for this unexpected behavior in this old post.
RegSvr32 just calls the DllRegisterServer entry point in your code.
What gets written to the registry is entirely up to your filter. If
you are using the standard baseclass call to AMovieDllRegisterServer2
as your DllRegisterServer, I would suspect that something went wrong
in setting up g_hInst, which should have been done by the call
DllEntryPoint in your DllMain.
…
The DllMain is not being called, so g_hInst stays 0 and
GetModuleFileNameA(...) returns the name of the currently executing
program instead of my filter.
The filter is using MFC (dynamically linked), and its DllMain() version is not calling the DllEntryPoint() function. I had to override the MFC DllMain() by adding extern "C" { int _afxForceUSRDLL; } as described in an answer to this question and call DllEntryPoint() myself to fix the registration problem. (I also found a missing #define was the reason for the property page not showing up).
I'm putting together a dll for use with MQL4 using nugent and vb.net and it's going pretty good so far.
In my dll I am setting a flag when a condition is met so that I don't have to keep checking each time the function is called. This works fine but what I realize it that the flag is remaining set and in memory even if I remove the EA that created the dll from the chart.
The flag is declared within a function in the module as static.
If I close the terminal and then open it again the flag has gone and the process starts again.
How can I remove the dll from memory and release it's resources (the static variable) on removal of the EA?
I'm thinking it should maybe call a function in the deinit but I can't find any VB.net examples of a dll 'killing' itself.
Any ideas would be much appreciated.
Steve
Update: I just had a thought. Maybe the dll is not supposed to end on removal of the EA from the chart? Could it be like that by design? If so I can just set the flag to false manually I guess.
But wouldn't that mean that if I add the EA to the chart again there will be another instance of the dll?
If anybody has a definitive answer though that would be great.
DLLs to be used in MQL4 expose functions that can extend the functionality offered by MT4. From what i understand about DLLs, they DO NOT offer data retention. Like, in your case, when you call a function of the DLL in your MT4 code, the data is retained for the duration of that call. When you restart the EA, the data is gone and everything is back to default values.
Hope this helps.
The LoadLibrary function is returning to me the error code 182. From MSDN:
ERROR_INVALID_ORDINAL: "The operating system cannot run %1"
Does anyone have a better description of what this error is?
Very obscure error. The term "ordinal" is however strongly associated with a DLL. A DLL contains a list of exported functions as well as a list of imported functions. Other DLLs that it has a dependency on. These exports and imports usually have a name, but that's not required. They always have a number, the number is the "ordinal".
To start diagnosing this, use the SDK's Dumpbin.exe tool. Run this first:
Dumpbin /exports Blah.dll
and look at the list of exports. You should see the ordinal as well as the name. If that all checks out, run
Dumpbin /imports Blah.dll
to get a list of the dependencies. Odds are good that it has a dependency on a function in another DLL by number that this DLL doesn't have. Something like that anyway. You can probably make it less laborious by using the DependencyWalker tool. If the first step fails then something went drastically wrong when the DLL was built. If the second step fails then you're probably looking at some kind of DLL Hell problem.
Are you sure that this error is coming from LoadLibrary? Windows DLLs allow you to specify exports by name and ordinal value. That is, each function can be identified by a number. If you call GetProcAddress and specify an invalid ordinal, then you'll get this error.
My best guess is that the DLL that you're loading is calling GetProcAddress in its DllMain and specifying an invalid ordinal. This causes it to fail, and when you call GetLastError, you get ERROR_INVALID_ORDINAL since that's the last error that occurred.
I have a Microsoft Word template with some code and some references, that has been working fine for months but has just started throwing up a spurious "User-defined type not defined" error whenever I open it or try to compile it.
I know it's a spurious error because I haven't made any significant changes to the code. In fact, I've rolled the code back to the last deployed version (which I know works fine) and I still get the error. I've also commented out all the code in the template and I still get the error. I've also removed and re-added all references (same error), and removed all the references and added them back, one by one, until the resultant compile errors are resolved, at which point I'm left with the spurious "User-defined type not defined" error. (I'm going to call this a UDTND error, from now, to avoid driving you all mad.) I think the error started popping up after I rebooted my PC. It only happens with this template, but I don't see how it can be anything to do with this template.
Interestingly, the error is subtly different from a genuine UDTND error in the following ways:
No code is highlighted when the error is displayed.
The dialog is titled "Microsoft Visual Basic", and contains the error message but, unlike a real UDTND error, doesn't contain the text "Compile error:";
It happens when the template is opened, not just when it's compiled (at least, I think that's different from a normal error).
I've tried Googling it but I just get a bazillion results from novice developers asking why they get this error, with responses telling them that they either need to declare the missing type, correct the spelling of the offending variable type, or add a reference to a missing library. I've been banging my head against my screen all afternoon, and that's helped about as much as all the other things I've tried (i.e. not at all). I have a feeling that this is something to do with a messed-up reference, but afaict they're all fine, and I've removed and re-added them, which I would expect to resolve that sort of problem.
Any ideas...?
Your trouble-shooting on References is sound. Once upon a time (and I don't recall the precise error) I was at the same point, and the reference ordering was the key. When you're designating References, you'll notice a "Priority" adjustment feature. Experiment with that and you may solve this.
I have had "User-defined type not defined" problem on several occasions when compiling Microsoft Visual Basic 6 (MSVB6) code that was compiling without a problem earlier. It seems to happen after I have had a long coding session without rebooting the computer. As you can guess, I have been using Microsoft operating systems. I currently am using Windows XP. Rebooting the computer usually fixes the problem as it so often does on Microsoft operating systems.
I have read that fully qualifying declarations also can help, e.g., "Dim oBar as Foo.Bar" instead of "Dim oBar as Bar". I have not tried this approach however.
I had a very similar problem.
My problem appeared (I think) just after I made a Search and Replace that I canceled (Ctrl+Z). There was not highligting of the problem, only the ""User-defined type not defined" error message when I compiled.
I tried:
1) restarting computer
2) changing reference ordering
3) removing functions/procedures, modules one at a time.
Didn't work. My project was written in Excel VBA and here was the solution I found.
THE SOLUTION:
I opened a new Excel file and opened the Visual Basic Editor. I then copied all Forms, Modules, and Class Modules one by one into the new file. I then Copied the Control Objects (3 Commandbuttons) from the old sheet into the new one. Now the new file was identical to the old project - only the ""User-defined type not defined" had gone and problem was solved.
Yea references would be the first step in troubleshooting this problem as already stated, but failing that id start commenting out the code in any event procedures running at start up (my experience is only with Access VBA though)
I had the same problem with Excel 2013.
It started when I did a search and replace on the name of a Custom Class.
I changed the name of the Class after I did the search and replace on all references to it and the spurious error started immediately after that.
I reverted to an earlier version ad confirmed that the problem was not there and then did the same search and replace and re-name and got the exact same behaviour again.
The Custom Class that I changed the name of only had one consumer and it was also a custom class.
I exported, removed and re-loaded the sole consumer class and the problem was fixed.
Check out this link for a Microsoft bug that might be related.
TLDR:
The reference to a package/addin/whatever probably needs to be re-referenced. Check Tools -> References in the Menu.
Also it appears that if you install Microsoft Security Advisory 960715, that certain controls are killed. There are fixes which may or may not work for you. A good article is on this blog:
VSOD Blog
I've got a really strange error and any light that anyone can shed on this would be greatly appreciated.
I made some changes to some VB6 source which builds a COM object. The automated build which builds our app returned an error. No problem I thought--I'll just back out my changes. Well backing out my changes isn't making the problem go away.
Specifically when I attempt to build the app via a .vbg file, with a command line like path\to\vb6\vb6 ProjectFile.vbg /make
I get a message
"Compile Error in File '', Line : Object library
invalid or contains references to object definitions that could not be
found."
As I said, I reverted the source code so I'm really stumped as to why this error is still occurring. Any VB6 gurus around who might be able to point me at an answer?
I can post the exact code in question but the fact that it was building correctly, stopped building correctly and now refuses to build correctly makes me think this is not a problem with my code but rather some problem in the environment. Like something got put in the registry as a result of the previous build error.
Any tips, hints, or suggestions greatly welcome. I realize my question is a bit sketchy but I'm not even sure what's important to include and what isn't.
EDIT 1:
Thanks for the excellent suggestions guys. I think it is something to do with VB6 doing some sort of auto-registration.
Just to add a bit more detail: this problem does not occur when I build the referenced vbp file from the IDE. It only happens on the make on the .vbg which contains the vbp. Also the build tool in question automatically pulls latest source and the error happens on both my local box and the dedicated build box.
EDIT 2:
Hi again all,
The release engineering fellow figured out how to get this to build in his build environment so it's currently ok. Once we're past this crunch, I'll try to interrogate him about what he did and share the details with everyone.
Thanks again for all the great suggestions. This is what's so great about SO; that is, I asked about a 10-year-old technology and I got several great and on-point ideas.
Make sure that the VBG and all the VBP's got rolled back as well. That error is consistent with a project trying to reference a CLSID that is no longer valid for the dependency. Have you tried loading up the project group and building from the IDE, if that works and you save and check in all the changes to the group and project files, you might be fixed up.
I'm guessing the fact that you mention that it was a COM component might be the source of the problem. If any of the public method's or properties have changed then I seem to remember that VB6 will change the interface GUIDs and auto register the new ones.
My suggestion would be to check the registry to look for any mention of the component name, make a note of any associated CLSIDs, back up the registry, and then delete the references.
As cmsjr mentions it could also be a bad CLSID reference in your .vbp files.
The other option is that the failure has caused a problem with some .tlb (type library) or olb (object library) files.
The best thing to do is move all your compatibility DLL to a separate and combined directory. The reason for this is control over what VB6 is using to check for binary compatibility. In addition the Typelibs that are generated IMPORT the references. So if you using Binary DLL Ver 10 for compatibility however the import is pulling in Binary DLL Ver 9 you will have issues. By keeping all the libraries in a single folder and pointing your projects to the DLLs in that folder you ensure that the respective TypeLib Import the correct version.
Finally if you have multiple levels of DLL reference each other. You may run into mysterious error where the VB6 is unable to compile using binary compatibility. In such cases you need to compile the lowest DLL in the hierarchy (Utility DLL perhaps) copy it over into the compatibility folders. Work your way up the chain until everything compiles in one shot again.
This is because if have DLL A reference DLL B which Reference DLL C. VB6 will get sometimes get confused if you make a change to A and C. will compile fine but A will not until the compatibility libraries are updated.
Hunt down and delete any .obj and .exp files that may be lying around from the previous failed build.
You will have to open the project & re-type in the lines that you changed.
Save the project alongwith VBG and re-compile after that.
I think that will fix it.
EDIT: The idea is that the cls/bas file remember the class (CLSID) that you used. So, if you change the references but don't change the lines in the cls/bas - it is a mismatch of type (what was referenced vs what is typed in cls/bas file).