I am creating a program which will be able to connect automatically to a wireless network. For doing that, I am using a library called ManagedWifi, which uses the library "wlanapi.dll". When I try to use the code on Windows Vista, everything is fine, but when I use it on Windows XP it fails. I have checked that it has Service Pack 3 installed, and "wlanapi.dll" is located in Windows/system32. The problem is when ManagedWifi calls this method:
[DllImport("wlanapi.dll")]
public static extern int WlanSetProfile(
[In] IntPtr clientHandle,
[In, MarshalAs(UnmanagedType.LPStruct)] Guid interfaceGuid,
[In] WlanProfileFlags flags,
[In, MarshalAs(UnmanagedType.LPWStr)] string profileXml,
[In, Optional, MarshalAs(UnmanagedType.LPWStr)] string allUserProfileSecurity,
[In] bool overwrite,
[In] IntPtr pReserved,
[Out] out WlanReasonCode reasonCode);
You can view a description for this method here. The error I am receiving is the following: 1206 (ERROR_BAD_PROFILE). As you can see in this page it is a known error, and the only thing I have to do is to download and install the hotfix. Well, I have done that and the error is still there. The profile is correct, because I get it from a call to WlanGetProfile
I just want to connect to a network using WlanConnect, but as you can see in the function's page: Windows XP with SP3 and Wireless LAN API for Windows XP with SP2: You can only use WlanConnect to connect to networks on the preferred network list. To add a network to the preferred network list, call WlanSetProfile.
I am really desperate, I've been fighting to this error some days, and I need to go through it...
And, if I try to call WlanConnect method without calling SetProfile, the result is always the same: it doesn't connect.
I will appreciate any idea you can provide with.
There's a WlanReasonCode out parameter which should tell you why the profile is invalid. Is that any help?
What machine did you get the profile from? IIRC XP supports only a subset of profiles supported on later platforms.
Oh and I don't know if you can WlanConnect to an IBSS (ad-hoc) network on XP.
Related
I have an application that relies on the in built Microsoft GS Wavetable Synth. It has worked flawlessly on Windows XP, Vista, 7, 8 and 8.1. While the first call to midiOutOpen on Windows 10 works, subsequent calls result in error code 1, meaning 'Unspecified error'. The code is simple:
result = midiOutOpen(&_midiOutHandle, midiOutputDevice, NULL, 0, CALLBACK_NULL);
Any ideas regarding how to resolve this hugely appreciated.
I see it. Tracing through the machine code, I see the modMessage() function fail and return MMSYSERR_ERROR. Exactly why isn't clear to me, it looks like a missing initialization problem.
What is strange about this mishap is that there are not a lot of complaints about it, you'd expect plenty of other programs fall over as well. Or for that matter for them to be tested before Win10 shipped. Next thing I tried is adding the one thing that happens in any non-trivial audio app that I skipped in my test program. Partly inspired by seeing "ATL" back in the symbols of modMessage, although it wasn't anywhere close. I added this as the first line in main():
CoInitializeEx(NULL, COINIT_MULTITHREADED);
Badaboom, no more error. Use COINIT_APARTMENTTHREADED if you call this on the main thread of a UI thread. CoUninitialize() at the end to clean up.
Explaining it is difficult, initializing COM should not be necessary when you use MIDI. With it in place, calling midiOutOpen gets one more DLL loaded, clbcatq.dll. That's a COM+ support module. So sure looks like Win10 requires COM to be initialized.
I put a MessageBox (with nothing important to say) just before midiOutOpen, and IT WORKED!
I'm using Visual Studio 2013 C++.
WASAPI doesn't work for me anymore in sharing mode, although I think I'll be able to make it work.
When I use the CoInitializeEx(NULL, COINIT_MULTITHREADED), this helps for the midi open problem but has bad influence for using mciSendString with opening an MP3 song, which results always in error 266 in same program. Eg.:
open "d:\\music\\Fernando.mp3" type MPEGVideo alias Fernando.mp3 wait
(without the CoInitializeEx this open works and the mp3 song plays in Windows 10).
On some Windows 10 Systems the midi and mp3 open well without calling the CoInitializeEx, on others it does not play midi. It is not documented in MCI api that it must be called and causes indetermined problems. For me it is not clear when or why it must be called and when I should better not call it.
The Windows 10 incompatibility relating MCI of Microsoft is intolerable.
All Systems since XP are MCI compatible and only Windows 10 causes troubles.
I am trying to display a new Word document inside a Widget, using OLE. This works fine as long as I compile my application under x86 architecture. Now I tried porting my application to x64 and it stopped working. The call to OleCreate() fails with REGDB_E_CLASSNOTREG.
CLSID clsID;
IUnknown* pIUnknown;
HRESULT res = CLSIDFromProgID(L"Word.Document.8", &clsID);
if (SUCCEEDED(res)) {
res = OleCreate(clsID, IID_IUnknown, OLERENDER_DRAW, NULL, NULL, storage, reinterpret_cast<void**>(&pIUnknown));
}
After some research I came across some solutions, but none of them were applicable.
I can't set my compiler to x86 when I'm trying to port my application to x64 so following Post hasn't solved my problem.
I tried calling regsvr32.exe withC:\Windows\System32\ole32.dll but it didn't change the result.
I tried installing the hotpatch, which was shipped by microsoft to fix the same problem with OleCreateFromFile(). Sadly it doesn't fix the problem for OleCreate() - hotfix
The only solution, which worked so far was to copy the content of HKLM\SOFTWARE\SysWow64\Classes\CLSID\<CLSID of Word Document> into HKLM\SOFTWARE\Classes\CLSID\<CLSID of Word Document> but this is more of a hack than a fix, because I would have to modify the registry of every machine on which I want to run my application. Since this task requires administrator privileges, I can't do this from inside my application.
I need a solution which works and doesn't force me to manually alter registry entries.
I'm running my application on a Windows 7 Professional SP1 64-Bit machine with a 32-Bit Office 2010.
After some more testing I found the solution to the problem, which was to use Word.Document instead of Word.Document.8 as progID.
I have don't know why this seems to be a problem with 64-Bit compilation. The thing, I noticed though was that CLSIDFromProgID() now resolves to a different CLSID.
My 32-bit MFC C++ (VS 2010) application uses a 32-bit dll COM component that is registered by our installer with the vsdrfCOM option. The application runs on Windows 7 Pro 64-bit.
We are getting a new error that is intermittent on only one system that is based on the same drive image as several other systems that have never seen this error. We are calling this code several times a second. Looks like there is room to make more efficient, but why never any problems before?
// Initialize SPC I/O Library COM object
(void)CoInitialize(NULL); // Initialize COM
CComPtr<IGSpcIO> pSpcIO; // define COM pointer to the SPC I/O Library object
HRESULT hr = pSpcIO.CoCreateInstance(CLSID_GSpcIO); // Create COM pointer
The code above works most of the time but I'm getting an intermittent failure on the CoCreateInstance() call.
What other issues should I be looking for that might be returning 0x80040154?
I have no idea why it would be intermittent. I would use procmon.exe to look at registry access and file access to see what the conditions are when it fails. You need to know whether it cannot find the class in the registry or whether it is having problems loading the DLL (COM server).
On Linux it seems getpid() is the simplest system call to invoke to best-measure the time taken for a system call. Would somebody be able to refer me to a simple windows system call I could make to measure the time spent changing to kernel mode and back please?
I did google and found a list of Windows System calls on MSDN website, but they all referred to opening files- which seemed strange:
http://msdn.microsoft.com/en-us/library/t0wd4t32.aspx
I am on Windows 7 64 bit.
My suggestion (and this is just based on intuition) is to try something like
CloseHandle(NULL)
or
WaitForMultipleObjectsEx(0, NULL, 0, 0, FALSE)
on the grounds that it should be a no-op. However, I don't have any evidence to support this.
Update
A little benchmarking on Win8.1 x64 shows the (undocumented) NtDisplayString(NULL) function is even faster, followed by the semi-documented NtAllocateLocallyUniqueId(&some_luid). You'll have to dynamically load them from NTDLL using GetProcAddress; the signatures are:
NTSTATUS NTAPI PNtAllocateLocallyUniqueId(PLUID LUID);
NTSTATUS NTAPI PNtDisplayString(PUNICODE_STRING DisplayString);
I have been trying to use WMI classes (using C++) to manage Virtual Switches in Hyperv like Creation,Deletion, Attach a Virtual Network to a VM etc. I was able to do everything perfectly on Windows 2008 R2. But none of them are working fine on Windows 2012.
For example when I create an externalnetwork I call a method called CreateSwitchPort on the object of the class Msvm_VirtualSwitchManagementService. It's working on 2k8R2 but fails with out parameter return value as 32768 which means failure. Can anyone point out why does the method return an error? How to debug the issue? Are there any permissions I should be giving. Any help in the regard is highly appreciated.
--Ramakrishna.
Hyper-V 2012 supports the previous WMI API, and I have successfully used it. Hyper-V 2012 introduces a v2 API, but this is irrelevant to you.
CreateSwitchPort is a very straightforward call. Here is an example in Python that is quite readable. The Python call returns a tuple that the [out] parameters are added to.
#Create a port on the vswitch.
(new_port, ret_val) = switch_svc.CreateSwitchPort(
Name=str(uuid.uuid4()),
FriendlyName=vm_name,
ScopeOfResidence="",
VirtualSwitch=extswitch.path_())
Check that the VirtualSwitch parameter is valid. I use a WMI query shown below to get this object. It fails if the VirtualSwitch is not connected to an external NIC. Is your query successful?
return self._conn.Msvm_ExternalEthernetPort(IsBound='TRUE')[0]\
.associators(wmi_result_class='Msvm_SwitchLANEndpoint')[0]\
.associators(wmi_result_class='Msvm_SwitchPort')[0]\
.associators(wmi_result_class='Msvm_VirtualSwitch')[0]
Next, look to see if the name Name parameter needs to be unique. If you use a static name, the call might fail because of a naming conflict.
If none of this helps, then start inspecting the Hyper-V WMI objects in realtime. You can use Python and the WMI bindings for Python by Tim Golden.