I'm developing an application using Wosa/XFS and the current problem is that it produce and error on startup saying "The application was unable to start correctly (0xc0000142). Click Ok to close the application."
This is produced by Wfs_Startup call.
BOOL Wfs_Startup(void)
{
WFSVERSION WfsVersion;
return (WFSStartUp(RECOGNISED_VERSIONS,
&WfsVersion) == WFS_SUCCESS);
}
I don't know what may be the course of this error whether it because I didn't load the NI_XFSMgr.DLL or it the 3 DLL files that I put on System32 directory.
Anyone with a knowledge on WOSA/XFS please help me out with the solution. My application is console based at the moment.
I thank you.
This error may occur when you haven't configure xfs registry correctly.
Check your HKEY_LOCAL_MACHINE\SOFTWARE\XFS\XFS_MANAGER node.
All values must be correct.
Another reason may be your application has no access to xfs shared memory file.
Path to shared memory file is set at HKEY_LOCAL_MACHINE\SOFTWARE\XFS\XFS_MANAGER ShareFileName parameter.
This isn't an XFS problem.
This is due to the DLLs you put in to the system32 folder not being signed or digitally no longer valid.
More info and a trick to go pass this can be found from here
The easier solution would be to put those DLLs in the folder where your application is (And that to be outside of system32).
Related
When I'm running any project in Code Blocks I see this:
or
What should i do?
Thank you for your question and for using CodeBlocks as IDE.
The error message you are getting is because codeBlocks has no 'write' privileges to the folder where it wants to place the binary (or executable). You need to change the privileges of the folder where you ave your projects stored to Read/Write/Execute for all.
If you need to know how to do that, you need to put the specs of your system in the comments, I will tell you here on how to.
KR
Hewi
You usually get this message when you try to recompile an executable that is already running.
If you got this error, you should simply close your application. If you can't see an application window and you're still getting the error, open Task manager (Ctrl+Shift+Esc), find your program in processes list and close it from here.
I have a simple C++ program (command line with Boost libraries) that I developed under Visual Studio Community 2013. I want to deploy it on other Windows computers, so I am testing InstallShield LE in Visual to do so (I am new with InstallShield). I added an InstallShield project in the current solution and I managed to create a setup.exe.
When I test it on another computer, setup seems OK but when I try the application, I have weird error:
MyProgramm.exe --help
Sends correct result (but it is not really interesting).
MyProgramm.exe -i InputDirectory -o OutputDirectory
Fails with a Windows displaying this message:
A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available.
What did I miss?
I built Release configuration only. How can I be sure that I have checked all the merge modules or InstallShield prerequisite ?
You will have to identify what is going wrong. Typically the symptom you describe indicates that an exception caused the process to terminate. One common source of such exceptions is misuse of an invalid pointer.
But why does it work on one computer and not another? Depending on the code it could be random incidental things. But as long as this repeats every time, it's more likely to be environmental. This could mean a missing data file, a missing registry key, a missing service, or a missing .dll dependency.
Because you can run the program at least one way, you know it's not a static dependency. If it were, you'd get a message about an inability to load some file or one of its dependencies. But instead in some execution paths you see a crash. So if it's a dependency, it's what InstallShield calls a dynamic dependency. I'm not personally a big fan of it (I'd much rather be told exactly what might be required), but there is a dynamic dependency scanning wizard that can help identify such files and include them into the project.
That will only help if the problem stems from something like this:
HMODULE hMod = ::LoadLibrary(TEXT("SomeFunky.dll"));
SOMEPROC proc = (SOMEPROC)::GetProcAddress(hMod, "SomeFunkyProc");
int result = proc(some, args);
Or maybe from a COM-related variant of that that looks something like this:
CComPtr<ISomeFace> spSomeFace;
HRESULT hr = spSomeFace.CoCreateInstance(CLSID_SomeFace);
hr = spSomeFace->SomeMethod(some, args);
The common problem here is that neither of these blocks of code verifies the function it's calling is safe to call. In the first case, proc (or even hMod) could be null; in the second, spSomeFace might not have been successfully created an instance. While the code can (and should) prevent these scenarios from crashing, fixing the crash will not get your application to actually do what it's supposed to, and you'll still have to fix the reason that the procedure, dll, or instance could not be initialized as desired.
It's also possible that you're missing a data file or registry key that at some point is being used in an incorrect fashion. For example, the code may assume a data file exists, build a pointer from data it reads, and fail to work correctly because the file wasn't available and thus the buffer it read into was never actually initialized.
So in short, to solve this, if it's not a dependency scenario that the dynamic dependency scanner can assist with, you may have to debug the code in question. You could try tools like Process Monitor and look for errors that involve your application shortly before the crash. If you have source and symbols, you could try running the program under WinDbg to figure out exactly what was crashing, and then try to figure out why it does so in one environment but not another. But from just the information you've already provided, there's nobody that can tell you the answer.
I've developed a program by a customer who's experiencing when he do a certain operation. This isn't happening always on the same place and on the same data and, moreover, it is not happening nor in my local developing machine nor in my test Virtual Machine (which is free of all developing equipment).
Given these conditions, I've decided to compile with MAP (enabled in Configuring Properties-> Linker->Debugger with option /MAP) to see which function is causing crash.
If I've correctly understood, when the program crash I've to check down the offset error and then, search in my MAP under the column RVA+BASE:
Address Publics by Value Rva+Base Lib:Object
0001:00037af0 ?PersonalizzaPlancia#CDlgGestioneDatiProgetto#MosaicoDialogs##IAEXXZ 00438af0 f DlgGestioneDatiProgetto.obj
0001:00038000 ?SalvaTemporanei#CDlgGestioneDatiProgetto#MosaicoDialogs##IAEXXZ 00439000 f DlgGestioneDatiProgetto.obj
Actually, my crash happens at offset: 00038C90 So I should think that it's somewhere in the method:
MosaicoDialogs::CDlgGestioneDatiProgetto::PersonalizzaPlancia
but this is not absolutely possible, so assuming that the computer can't be wrong, I'm the one who's doing it bad.
Can someone explain me how to read MAP in correct way?
don't bother - instead, build the project with symbols enabled and strip them into a pdb file.
Modify the program a little, to write a minidump when it crashes using a unhandled exception handler
Give the newly compiled program to the customer, and when it crashes call MiniDumpWriteDump.
Ask the customer to send this .dmp file to you, and you then simply load it up in Visual Studio (or WinDbg) and it will match up the symbols to the program, and will also match up the code. You should be able to see the exact line of code and some of the variables involved. (if using VS, when you load the .dmp file, top right corner will be an option to "start debugging" click that as it will 'start debugging' at the point of the crash)
Try it first locally - put a div by zero error somewhere in your program and see if you can debug the dump after its been run. Note that you must keep the exact same symbol file for each build of your program - they match exactly. You cannot expect a symbol file for one build to match another build, even if nothing changed.
There are tutorials for this kind of thing, such as this one from CodeProject that looks like it describes what you need.
Reading of MAP files to find out crash location is explained nicely in this code project article.
http://www.codeproject.com/Articles/3472/Finding-crash-information-using-the-MAP-file
Hope helps.
For postmortem debugging, there's an alternative that would not required the use of a map file. Rather, it would require you to create a simple registry script to enable some WER (Windows Error Reporting) flags to trap the crash dump file. First, build your application with debug symbols. Then, follow the instructions for Collecting User-Mode Dumps. Basically, you create a sub key under the "LocalDumps" key. This sub key must be the name of your application, for example, "myapplication.exe". Then, create the "DumpCount", "DumpType", and "DumpFolder" keys/values. Have the user run the registry script. This will enable trapping the dump locally. Then, have the user force the crash to collect the dump file. The user can then send the dump file to you to debug using the symbols you created earlier. Lastly, you'll need to create a registry script that removes the keys/values you added to the registry.
I've been trying to get a program that worked on Windows 2000 to work on Windows 2003. Everything I've had to do so far to get the program to work on Windows 2003 has had to do with incorrect configuration. Right now, this piece of code:
chr = pAdapterEnvPtr.CreateInstance(__uuidof(PFADAPTERMNGLib::PFAdapterEnv));
is returning:
0x8007007E
or in other words:
The specified module could not be found.
I have two other programs and another .dll and I can successfully create instances of those classes. But this seems to fail.
I have used Procmon to try to figure out what the program can't find, but Procmon did not display anything that could indicate that the program could not find something.
In OleView, if I try to create an instance of the class, I see the following image:
If you look on the left side of the image, trying to create an instance of PFComgMng gives me the same error. (PFAdapterEnv and PFCompMng use the same process, PFAdapterMng.exe.) However, PFMQMonitor, PFSend, and PFTrace all work correctly. (Which use PFMQListen.exe, PFSend.dll, and PFTraceService.exe.)
Another thing that I wanted to note is that the following piece of code:
hr = pPFCompMng.CreateInstance(__uuidof(PFADAPTERMNGLib::PFCompMng));
works perfectly fine when it gets called earlier from PFAdapterMng.exe. So it seems like PFAdapterMng.exe can successfully find the module and create the instance, but any other processes that try to create either of the instances of the classes within PFAdapterMng.exe can't find the module, resulting in this error.
Since Procmon isn't helping with this specific case, does anyone know what I could do to figure out what's keeping other processes from finding the module?
UPDATE:
I can't run Dependency Walker with profiling because PFAdapterMng.exe and PFTraceService.exe must be run as services. I tried to run Dependency Walker while profiling OleView and tried to create instances of PFAdapterEnv and PFCompMng to try to find out why I was getting the Module not found message box. Unfortunately, Dependency Walker didn't show that anything was missing.
UPDATE2:
Maybe I missed something in the Procmon log, so I created a new log by capturing events right before I stepped over the call to CreateInstance and right after the call. Maybe someone else could take a look and tell me if i missed it? I simply can't find any indications that PFMQListen.exe could not find something..
Here's a link to a zipped folder with a Procmon file, a .csv file, and a .xml file.
http://www.mediafire.com/?07jq8zj7emmpsvd
UPDATE3:
So, I managed to get Dependency Walker running under Profile mode to create an instance of PFAdapterEnv. Dependency Walker did not find any missing .dll's.
So, Procmon doesn't show anything, and neither does Dependency Walker. I was stepping through the code at the assembly level with ollydbg, and I noticed that the error was created in the function NdrClientCall2. I don't know if this means anything.
Any ideas as to what else I can try? Do people need more information to help me solve this problem? If so, please ask.
UPDATE4:
I tried using /RegServer to register the applications, and it worked. I tried using /RegServer previously, where I just unregistered everything using /UnregServer. This time, I also deleted the component from Component Services which I needed to have because I wanted to run PFAdapterMng under another identity.
So, it seems like everything works when running on /RegServer and double-clicking the applications. However, I would like everything to run under a different configuration.
How do I configure everything to get the applications to work as follows:
PFAdapterMng.exe - Register as /Service and run under another identity through services.msc
PFTraceServer.exe - Register as /Service and run under another identity through services.msc
PFMQListen.exe - Register as /RegServer which will be started by PFAdapterMng
PFMQSend.dll - Registered with Regsvr32 and loaded by PFAdapterMng
Thanks,
Krzys
My guess is that it is related to the search path of some DLL dependencies of the executable.
You can try the "Dependency Walker" on every module to see if all DLL are available: http://www.dependencywalker.com/
And update the search PATH if needed.
I wrote this C++ application that needs to check an INI file (“preference.ini”), and eventually modify it (e.g. if the user does not want to see the introduction form anymore). I created it in WinXP, and it works fine on the system where I compiled it (in many locations, including “Program Files”).
Problem:
In Win 7, it works fine if I put the complete program folder under “C”:\” (e.g. “C:\MyProgram”), but if I put it in “C:\Program Files (x86)\MyProgram”, it just retrieves some mysterious data (values not present in my INI file). When I change some settings and save them to file, it (apparently) save the changes (get no errors, but the changes are not there when I go and open the file...
I had some similar issue on a system with another WinXP system (not the one where I compiled it.
I used 'getcwd' to define the path at runtime, and I verified that it is getting it right, even under "Program Files (x86)":
char currentPath[MAXPATH];
getcwd(currentPath, MAXPATH);
std::string licensePath(currentPath);
licensePath.append("\\dat\\preference.ini");'
Any ideas? Thanks in advance for your help.
The answer is as #Kirill has already said - Win7 won't let you write data into Program Files unless you have higher than normal permissions (Run as Administrator). In this case it may be redirecting your file writes so that they still apear to work, but the data itself is not stored in Progam Files.
To add to his answer: In general (unless you want to run your app as an administrator), you should not write any program data to the Program Files folder.
Application settings should be stored in one of the AppData folders. You can get to your user's appdata manually by going to your start menu Search box (Vista/Win7) and typing %appdata%.
To find this location in your code, use SHGetFolderPath with CSIDL_APPDATA (current user) or CSIDL_COMMON_APPDATA (all users).
It could be related to that Windows use virtualization of the file system. You could read here about it. Check if your INI file is located in <root>\Users\<User_name>\AppData\Local\VirtualStore.
Seems to me that the licensePath: getcwd() + "\\dat\\preference.ini" is not what you would expect.
Log this value (console or in a log file) and see what exactly is the value of licencePath is when running you program from different folders.
This article is about game development but has the best description of how and why this happens that I've been able to find
http://msdn.microsoft.com/en-us/library/ee419001(VS.85).aspx
This paragraph from the article describes what is happening most likely -
Attempting to create or write a file
or directory under a folder which does
not grant write permission to the
process will fail under Windows Vista
if the application does not have
administrative privileges. If your
32-bit game executable is running in
legacy mode, because it did not
declare a requested execution level,
its write operations will succeed, but
they will be subjected to
virtualization as described in the
section "UAC Compatibility with Older
Games" later in this article.