it seems that location API is legacy(?). It does not work the GetReport(...) but works ok if you set RegisterForReport(...) The error I get is the follow
drivers\mobilepc\locationconvergence\api\winlegacyapi\dllapi\legacyapiimpltemplate.h(197)\LocationApi.dll!06552CA7: (caller: 06552D34) ReturnHr[PreRelease](1) tid(478) 8007139F The group or resource is not in the correct state to perform the requested operation.
[CLocationApiImplTemplate<class CLegacyPositionRequest,&struct __s_GUID const _GUID_e4e915a9_8344_4f88_9326_2adc071d4ff6>::GetReportInterval(!m_fRegistered)]
SalesMan::AGW_CLASS::AGWLocationWin8::GetLocation> HR=8007139F
SalesMan::AGW_CLASS::AGWLocationWin8::GetLocation> reportInterval=0
drivers\mobilepc\locationconvergence\api\winlegacyapi\dllapi\legacyapiimpltemplate.h(158)\LocationApi.dll!06554401: (caller: 06554448) ReturnHr[PreRelease](2) tid(478) 800700E8 The pipe is being closed.
[CLocationApiImplTemplate<class CLegacyPositionRequest,&struct __s_GUID const _GUID_e4e915a9_8344_4f88_9326_2adc071d4ff6>::GetReport(m_pLatLongReport == nullptr)]
drivers\mobilepc\locationconvergence\api\winlegacyapi\dllapi\legacypositionrequest.cpp(80)\LocationApi.dll!06554469: (caller: 06552BF2) ReturnHr[PreRelease](3) tid(478) 800700E8 The pipe is being closed.
[CLegacyPositionRequest::GetReport(__super::GetReport(ReportType, ppLocationReport))]
I must say here that RequestPermissions(...) works fine and returns OK. The same application on windows 8.1 works fine.
Anyone any idea?
Thank you in advance
George
I bypassed the problem by implementing the event driven location report.
Probably Windows 10 initialize slower the location than windows 8 , since the hardware is the same. I give it a 3 seconds report interval and reports back the lat/lon
George
Related
C++, Visual Studio 2019, Windows 10, SDK 10.0.22621.0
As part of my app's log file, I have collected a few bits of information about the user's computer.
I would start the query with:
static PDH_HQUERY cpuQuery;
static PDH_HCOUNTER cpuTotal;
PDH_STATUS status;
status = PdhOpenQuery(NULL, NULL, &cpuQuery);
and then get the bits of information starting with:
status = PdhAddCounter(cpuQuery, L"\\Processor(_Total)\\% Processor Time", NULL, &cpuTotal);
if (status != ERROR_SUCCESS) {
csData += _T("GetCPURAMStatsinThread - status Add Counter Processor Time Error 2 and return *********\n");
log_write(csData);
return -1;
}
I just noticed that I am now getting the error from PdhAddCounter as:
0xC0000BB8 (PDH_CSTATUS_NO_OBJECT) The specified object is not found on the system.
The only thing that I can think of that has changed since this used to work was that I updated to SDK 10.0.22621.0. I believe that it worked with 10.0.17763.0.
I have not been paying attention to these lines in the log file, but when a customer had a problem that had to do with how many cores his CPU had, and how many virtual processors it had, then that is when I realized that these lines have been erroring out.
I have a laptop that had Windows 7, but I upgraded it to Windows 10, and ran the app on that, and it did not error out. So, does this mean an issue with the Windows 10 update, or the SDK update?
Per my comments above with #Tony Lee I used the MS sample code to browse the counters on my local computer. There was a Processor Information selection vs my original Processor under which there was a Processor Time selection. In the choice box below that there was an all instances choice and a _Total choice. When I selected the _Total choice the buffer in the sample code stayed as NULL but if I selected the all instances the buffer filled with:
L"\Processor Information(*)\% Processor Time"
Plugging that string into PdhAddEnglishCounter() worked...
Edit it also worked with PdhAddCounter()
Using Processor instead of Processor Information and (_Total) Instead of (*) used to work in Windows 10. No telling why things have changed at least on some computer.
Ed
EDIT Important note. First is that the new code above also works on the laptop on which the original code worked. Second note is that I just realized that the desktop on which the original code failed is Windows 10 Home whereas the laptop on which the original code worked is Windows 10 Pro. That maybe the difference. Regardless, the new code works on both Home and Pro.
EDIT 2 The new code also ran fine on Windows 11 Home. I also see that my customer in whose log file I noticed the error line was on Windows 11 Home. That would insinuate that the Pro version still works with the legacy (see next comment by Tony Lee) Processor while the Home versions do not work with the legacy Processor but only with the new Processor Information
I have downloaded a Windows 7 x32 Enterprise (IE11) hyper-v image from Microsoft website to test a research project.
For some reason all the Ntdll functions I call (syscall) return STATUS_WAIT_0. I mean all of them that I have tested including RtlGetVersion, NtAllocateVirtualMemory, NtCreateFile and more.
Could this be because it's a virtual machine ? Or could it be because I do direct system calls ?
Please advise, I have tested my project under non-virtual machines including latest Windows 10 and it works fine so I doubt it's my code.
Update:
STATUS_WAIT_0 can be considered as STATUS_SUCCESS since it's value is both 0.
Ntdll function basically returns a NTSTATUS, like RtlGetVersion,NtAllocateVirtualMemory,NtCreateFile and more.
The following document contains the common usage details of the NTSTATUS values
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55
Return value/code:
0x00000000
STATUS_SUCCESS/STATUS_WAIT_0
Description:
The operation completed successfully.
The caller specified WaitAny for WaitType and one of the dispatcher objects in the Object array has been set to the signaled state.
I have a test for a pixel shader that does some rendering and compares the result to a reference image to verify that the shader produces an expected output. When this test is run on a CI machine, it is on a VM without a GPU, so I call D3D11CreateDevice with D3D_DRIVER_TYPE_REFERENCE to use the reference rasterizer. We have been doing this for years without issue on a Windows 7 VM.
We are now trying to move to a Windows 10 VM for our CI tests. When I run the test here, various API calls start failing after some number of successful tests (on the order of 5000-10000) with DXGI_ERROR_DEVICE_REMOVED, and calling GetDeviceRemovedReason returns DXGI_ERROR_DRIVER_INTERNAL_ERROR. After some debugging I've found that the failure originates during a call to ID3D11DeviceContext::PSSetShader (yes, this returns void, but I found this via a breakpoint in KernelBase.dll!RaiseException). This call looks exactly like the thousands of previous calls to PSSetShader as far as I can tell. It doesn't appear to be a resource issue, the process is only using 8MB of memory when the error occurs, and the handle count is not growing.
I can reproduce the issue on multiple Win10 systems, and it succeeds on multiple Win7 systems. The big difference between the two is that on Win7, the API calls are going through d3d11ref.dll, and on Win10 they are going through d3d10warp.dll. I am not really familiar with what the differences are or why one or the other would be chosen, and MSDN's documentation is quite opaque on the subject. I know that both d3d11ref.dll and d3d10warp.dll are both present on both failing and passing systems; I don't know what the logic is for one or the other being loaded for the same set of calls, or why the d3d10warp library fails.
So, can someone explain the difference between the two, and/or suggest how I could get d3d11ref.dll to load in Windows 10? As far as I can tell it is a bug in d3d10warp.dll and for now I would just like to side-step it.
In case it matters, I am calling D3D11CreateDevice with the desired feature level set to D3D_FEATURE_LEVEL_11_0, and I verify that the same level is returned as acheived. I am passing 0 for creationFlags, and my D3D11_SDK_VERSION is defined as 7 in d3d11.h. Below is the call stack above PSSetShader when the failure occurs. This seems to be the first call that fails, and every call after it with a return code also fails.
KernelBase.dll!RaiseException()
KernelBase.dll!OutputDebugStringA()
d3d11.dll!CDevice::RemoveDevice(long)
d3d11.dll!NDXGI::CDevice::RemoveDevice()
d3d11.dll!CContext::UMSetError_()
d3d10warp.dll!UMDevice::MSCB_SetError(long,enum UMDevice::DDI_TYPE)
d3d10warp.dll!UMContext::SetShaderWithInterfaces(enum PIXELJIT_SHADER_STAGE,struct D3D10DDI_HSHADER,unsigned int,unsigned int const *,struct D3D11DDIARG_POINTERDATA const *)
d3d10warp.dll!UMDevice::PsSetShaderWithInterfaces(struct D3D10DDI_HDEVICE,struct D3D10DDI_HSHADER,unsigned int,unsigned int const *,struct D3D11DDIARG_POINTERDATA const *)
d3d11.dll!CContext::TID3D11DeviceContext_SetShaderWithInterfaces_<1,4>(class CContext *,struct ID3D11PixelShader *,struct ID3D11ClassInstance * const *,unsigned int)
d3d11.dll!CContext::TID3D11DeviceContext_SetShader_<1,4>()
MyTest.exe!MyFunctionThatCallsPSSetShader()
Update: With the D3D Debug layers enabled, I get the following additional output when the error occurs:
D3D11: Removing Device.
D3D11 WARNING: ID3D11Device::RemoveDevice: Device removal has been triggered for the following reason (DXGI_ERROR_DRIVER_INTERNAL_ERROR: There is strong evidence that the driver has performed an undefined operation; but it may be because the application performed an illegal or undefined operation to begin with.). [ EXECUTION WARNING #379: DEVICE_REMOVAL_PROCESS_POSSIBLY_AT_FAULT]
D3D11 ERROR: ID3D11DeviceContext::Map: Returning DXGI_ERROR_DEVICE_REMOVED, when a Resource was trying to be mapped with READ or READWRITE. [ RESOURCE_MANIPULATION ERROR #2097214: RESOURCE_MAP_DEVICEREMOVED_RETURN]
The third line about the call to Map happens after my test fails to notice and handle the device removed and later tries to map a texture, so I don't think that's related. The other is about what I expected; there's an error in the driver, and possibly my test is doing something bad to cause it. I still don't know what that might be, or why it worked in Windows 7.
Update 2: I have found that if I run my tests on Windows 10 in Windows 7 compatibility mode, there is no device removed error and all of my tests pass. It is still using d3d10warp.dll instead of d3d11ref.dll, so that wasn't exactly the problem. I'm not sure how to investigate "what am I doing that's incompatible with Windows 10 or its WARP device"; this might need to be a Microsoft support ticket.
The problem is that you haven't enabled the Windows 10 optional feature "Graphics Tools" on that system. That is how you install the DirectX 11/12 Debug Runtime on Windows 10 including Direct3D 11's reference device, WARP for DirectX 12, the DirectX SDK debug layer for DX11/DX12, etc.
WARP for DirectX 11 is available on all systems, not just those with the "Graphics Tools" feature. Generally speaking, most people have switched to using WARP instead of the software reference driver since it is a lot faster. If you are having crashes under WARP, you should investigate the source of those crashes by enabling the DEBUG device.
See this blog post.
Crystal Reports seems to have an 80 section per group limit
Environment:
Microsoft Windows XP
Professional
Version 2002
Service Pack 3
Crystal Reports XI (Release 1)
Calling the Crystal Reports Engine crpe32.dll version 11.0.0.1445
Via Crystal VCL 11 libraries
Via Borland C++Builder 6 Enterprise Suite Version 6.0 (Build 10.166)
I found the report containing 86 sections (in one group)
ran just fine using the Crystal Reports XI exe found at
C:\Program Files\Business Objects\Crystal Reports 11\crw32.exe
However, when I called the same report from an executable compiled
using Borland C++Builder -> VCL calls -> crpe32.dll
IT DID NOT PRINT.
I spent many frustrating hours debugging the exe.
I used the divide and conquer debugging approach and devised
a state machine that would do the following while logging every
state along the way:
Load the Engine via LoadEngine;
Open the Engine via OpenEngine;
Open the PrintJob via OpenJob;
Close the PrintJob via CloseJob;
Close the Engine via CloseEngine;
Unload the Engine via UnloadEngine;
I found that the report errored out at OpenJob
with Crpe1->Status() status crsJobFailed
Crpe1->LastErrorNumber() was "505: No print destination specified"
Here's the play by play (I output this to a file):
LoadEngine() started
LoadEngine() completed. The handle to CRPE32.DLL is: 728956928
EngineOpen() started
EngineOpen() completed. Engine is already opened.
JobIsOpen() started.
JobIsOpen() completed. The PrintJob is open.
Execute() started
Status() crsJobFailed
Execute() failed.
Error state.
LastErrorNumber 505: No print destination specified.
C:\REPORTS\ProblemReport.rpt
Please first call PEOutputToWindow or PEOutputToPrinter!
Execute <PEStartPrintJob>
Finished state.
Back to the report:
Deleting some /*comment*/ sections from the report brought the number of
sections down to 78 and voila ... the report printed out just fine from the
executable compiled on Borland C++Builder -> VCL calls -> crpe32.dll
My conclusion:
Avoid creating over 80 sections in a group.
As a workaround, you can add another group having
the same GROUP BY column (essentially, repeat the
same group) and create all the extra sections needed
in the new group (the repeated group).
It's the equivalent of writing the following SQL
SELECT
column1
column1
FROM table
GROUP BY
column1,
column1;
Has anyone else had this problem?
If yes, what solution have you devised?
Continuing investigation on a embedded WindowsMediaPlayer problem, i am trying to do simple file playback via a DirectShow in-process server:
::CoInitializeEx(0, COINIT_MULTITHREADED);
CComPtr<IGraphBuilder> spGraph;
spGraph.CoCreateInstance(CLSID_FilterGraph, 0, CLSCTX_INPROC_SERVER);
CComQIPtr<IMediaControl> spMediaControl(spGraph);
// ... later:
spGraph->RenderFile(L"c:\\foo.wav", 0); // fails with VFW_E_BAD_KEY
spMediaControl->Run();
Interestingly, this runs fine on both systems i tested on (Windows XP 32 & x64) when doing it in a stand-alone application.
It however fails in my real use-case, a NPAPI based browser plugin - i.e. a DLL loaded into Firefox/Chrome/Opera.
Does anyone have an idea what could be going wrong here?
Or ideas on what else to try?
Update: also asked on the Microsoft forums.
Update2:
IGraphBuilder::AddSourceFilter(path,path,&base) already fails with the following registry calls (as seen in process monitor):
"RegOpenKey","HKCU\Software\Classes\c","NAME NOT FOUND","Desired Access: Query Value, Maximum Allowed"
"RegOpenKey","HKCU\Software\Classes\Media Type\Extensions\.wav","NAME NOT FOUND","Desired Access: Read"
"RegOpenKey","HKCU\Software\Classes\Media Type","NAME NOT FOUND","Desired Access: Read"
It is reading the key from the wrong hive. It should use HKLM, not HKCU. The most likely reason for this is registry virtualization.