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.
Related
Our software is failing on the first call to EndPage() when trying to print to an HP M506 printer using the specific driver. It doesn't fail when using the HP Universal Print Driver but our customer is reluctant to use that because they say it is slower. The code is maybe 15 years old and must have printed to hundreds of different printer types over that period.
It only fails if the printer is set as the default. Even when it is the default, switching to a different printer and then back again in the print dialog makes it work.
The customer is using Windows 7 and I can reproduce the problem on Windows 7 (they have lent us one of their printers). They have tried it on Windows 10 where they say it also fails; I can't reproduce it on Windows 10 (or Windows 8.1).
The call to EndPage() is returning -1 when it fails - as far as I'm aware there is no extended error information for this. The code is using PrintDlg(); I've tried PrintDlgEx() but it made no difference.
When it is going to fail, the DriverVersion and DriverExtra fields in the DEVMODE structure after returning from PrintDlg() are both zero, which I would guess is an indication that something has already gone wrong at that point.
The application is currently built with Visual Studio 2013, is written in C/C++ (with a bit of C# thrown in, but no C# code needs to be executed to get the problem) and is 32-bit. All the versions of Windows mentioned above are 64-bit.
Well, I've "fixed" it. Before the call to PrintDlg() the DEVMODE was being allocated with GlobalAlloc(), locked with GlobalLock(), had some fields set and then unlocked with GlobalUnlock(). I removed the GlobalLock() and GlobalUnlock() and it now works.
My team is developing an application that is capable of recording videos and exporting the video into .wmv format file.
The export function is done via a method that utilizes windows API method derived from WMVCore.dll library.
However, on some PCs, this export function gets into crashes and according to the dump file taken from the crash, it appears that the last method called was WMVCore.WMIsContentProtected method. The call stack from the dump file is like below:
379fe8d8 65aa0cdb 299f94f0 00025800 379fe8f4
WMVCORE!WMIsContentProtected+0x4bc3 379fe970 6102e07e 1cae3f20
299f94f0 379fece8 WMVCORE!WMCreateWriterPushSink+0x1e278
It is really frustrating getting this crash without any more information out of the dump file. I also thought that the library might be corrupted on that specific PC, but there is no way to re-install the library as it comes with Windows Media Player. Any suggestion would be appreciated.
The code simply called WMVCore.WMCreateWriterPushSink which is followed by WMVCore.WMIsContentProtected. The OS version is Windows 7 Enterprise 64 bit. The application is a web based application on IE, in which case when the crash happens, IE would also crash and stop. The version of the WMVCore.dll is 12.0.7601.17514 and the question here is whether anyone has experienced the same issue and if yes, what sort of things can be tried/done to prevent this crash from happening?
My program is a dll that hooks into a running instance of IE. It's worked fine for years.
Recently I dusted it off and ran it, but the last line below fails with hr = 0x80040154:
#import <mshtml.tlb> rename("value", "theValue") rename("event", "theEvent")
#import <shdocvw.dll>
// ....
SHDocVw::IShellWindowsPtr spSHWinds;
HRESULT hr = m_spSHWinds.CreateInstance(__uuidof(SHDocVw::ShellWindows));
Could it matter that IE7 has been replaced by IE8? Where else should I look?
I'm using VS2008, if that matters.
Edited to add
I don't see that it could be a 32/64 bit issue - it ran fine last year on this same machine. The only thing that's changed (as far as I have noticed) is the version of IE, from 7 to 8.
Note to the bounty hunters:
I only have access to this system for a few hours a day (around 0:00 EST), so you may not get quick responses to your suggestions, but I will look into them.
If you think there are things I should be checking (registry values, for example), be specific.
Edited to add:
I now see that the first time I call CreateInstance, it returns 0x80070002, not 0x80040154.
That's going to be very hard to diagnose. The ShellWindows coclass is special, its CLSID registry key is HKEY_CLASSES_ROOT\CLSID\{9BA05972-F6A8-11CF-A442-00A0C90A8F39}. When you look there, you'll see nothing useful registered there. The background story is that this is a leftover of an ill-fated attempt to make the Windows shell resemble a web browser. Still visible today, enumerating the shell windows returns both Windows Explorer and Internet Explorer instances.
The SysInternals' ProcMon utility is almost always the weapon of choice to debug 0x80040154 errors but it falls flat here. You can see it probing the registry, and not finding what it is looking for, but then the program knows how to load ieframe.dll anyway. This can only work by the operating system intercepting the CoCreateInstance() call. Which makes sense in general, considering the coclass enumerates shell windows.
All you got left is the trial-and-error approach. Reinstall IE first, OS next. Or to shove the machine out of a 4th story window before it eats too much of your valuable time.
When the compiling of a project is complete (or at least when it says it does), I receive no window, no error message, or anything; VC++ freezes up and my computer basically stops responding altogether.
After about five minutes, Task Manager finally pops up and I'm able to close the program. Upon doing that, I see this:
I'm going to take a wild guess here and say something is wrong with the image above. On a side note, the process' (MSBuild.exe) don't (seem) to open all at once, but that may only seem that way because the computer becomes frozen multiple times until I shutdown vc++.
Is this a known issue and if so what should I do so I can compile programs without this issue once again?
Additional Information:
Windows 7
Microsoft Visual C++ 2010 xpress
Project Type(s): I've tried on "Windows Form Application" project and "Win32 Project", both produce the same results.
Compiling projects in VB works as it should. (in case this helps at all)
As suggested by Hans Passant, disabling avast! solved the problem.
Did any error pop up during installation?
The standard thing to do (that almost always helps) is rebooting, reinstalling, (rebooting,) and trying again. Chances are absolutely nobody knows what's going wrong (even MS).
I have an application that is built against OpenSceneGraph (2.6.1) and therefore indirectly OpenGL. The application initializes and begins to run, but then I get the following exception "attempt was made to execute an invalid lock sequence" in OpenGL32.dll. When I re-run it, I sometimes get this exception, and sometimes an exception about a "privileged instruction". The call stack looks like it is corrupted, so I can't really tell exactly where the exception is being thrown from. I ran the app quite a bit a couple of days ago and never saw this behavior. Since then I have added an else clause to a couple of ifs, and that is all. My app is a console application, is built with Visual Studio 2008, and it sets OpenScenGraph to SingleThreaded mode. Anybody seen this before? Any debugging tips?
Can you reproduce it with one of the standard examples?
Can you create a minimal app that causes this?
Do you have a machine with a different brand video card you can test it on (eg Nvidia vs. ATI) there are some issues with openscenegraph and bad OpenGL drivers.
Have you tried posting to osg-users#lists.openscenegraph.org
The problem turned out to be our app was picking up an incorrect version of the OpenGL DLL , instead of the one installed in System32.