I have serious problems with the "security" stuff. First, there is an installer package (PKG).
Works without problems on all (most?) macOS with catalina and newer (probably). But trying it on 10.11 and older results in macOS saying that it is corrupted or signature is invalid, and console contains this:
03.12.20 17:32:42,194 CoreServicesUIAgent[331]: Error -60005 creating authorization
It has been signed and notarized, so this looks like a bug in macOS.
And then there's another software we make, this time it is installed using an APP. Again, codesigned and notarized and works on most macOS systems, including the older ones, but this time there are rare machines, which end up with the exact same message and the console contains:
com.apple.xpc.launchd[1] (com.apple.xpc.launchd.oneshot.0x10000006.setup.bin[2242]): removing service since it exited with consistent failurae - OSREASONEXEC | Gatekeeper policy blocked execution
Any ideas what is wrong exactly?
So it seems that Apple f*** up again - when you create installers on the new revolutionary awesome macOS Big sur, on some computers your installers won't pass Gatekeeper. Doing the same thing on Catalina -> everything fine. Damn you Apple...
Related
I upgraded from 10.3 (Rio) to 10.4 (Sydney) (with side-by-side installs), now having IDE docking exception, e.g.
Loading the desktop from "C:\Users\gary.walker\AppData\Roaming\Embarcadero\BDS\21.0\Default Layout.dst" for doc host windows "DockSite3" failed with message:
"EAccessViolation: Access violation at address 50165CBF in module 'rtl270.bpl'. Read of address 33DEEBFF"
Deleting all .dst files has resolved the issue in at least one case (a coworker).
Also, when attempting to debug a program, I was having a hard failure during debug startup that prevented debugger use, before application began execution. I resolved this problem by copying my Default desktop to my debug desktop.
Another friend had pretty much the same issue and was able to fix it, unfortunately he does not know how he fixed it.
Question is does anyone know how to fix this?
I am still waiting for an answer from Embarcadero and this is causing us real problems at the moment.
I received an answer from Embarcadero support.
It fixed the problem for me until I adjusted my desktops to the way I wanted them and them - still better than nothing. I suspect there is no solid work-around at this point in time. But, this may work well as long as you are not frequently changing your desktop layouts.
There were display layout changes introduced in 10.4.1 that cause the errors that you are seeing.
Shut the IDE down
In Windows Explorer navigate to: %AppData%\Embarcadero\BDS\21.0
Delete the *.dst files at that location (you can back them up first if desired)
In Windows Explorer navigate to the product's \bin directory. The default location is: 4. C:\Program Files (x86)\Embarcadero\Studio\21.0\bin
Copy the three default *.dst files from this location to the location in step 2
Start the IDE as normal
everyone. I am developing the LWF version WinPcap. It is already finished and under internal test currently. A colleague shared a Win7 x64 virtual machine with me remotely. Then I tried to install my new WinPcap installer on it and the machine just got frozen when installing the driver. The strange thing is that only this machine has this problem. I tested my own Win7 x86/x64 and Win8 x86/x64, no this issue.
I seem to encounter an alike problem before, but it is a debug version. My machine got recovered when a kernel debugger like WinDbg or VS2012 was attached. I thought this is a "int 3" problem. But the driver in this installer is a release version. So I don't know if this is because of the same issue. It is difficult to attach that remote machine becasue we are from different countries.
Also this should not be a deadlock issue like NdisWaitEvent waiting for an impossible event. Because I encountered that deadlock before, it only blocked the network part of Windows. Like froze the network properties window, stopped you from rebooting and so on. You can still use the other part of Windows.
So why this frozen problem occurs?
Here is all the code of my driver if you like to read:
https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/packetWin7/npf/npf/
The installer and other info are as below:
(Revision 32149)
Entire code base:
https://svn.nmap.org/nmap-exp/yang/NPcap-LWF
The installer only:
https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/installer/winpcap-nmap-4.1.3-NDIS6-1.2.0.exe
Build instructions:
https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/README-builds.txt
I want to get started with libspotify on my Win 7 machine but I dont have a clue on how to get it all setup so that I can even run the examples included in the pack. I have a Spotify Premium account and I have tried installing libspotify by copying libspotify.dll to c:\windows, c:\windows\system32 and to c:\windows\SysWOW64 and also changed the path variable to include the path where libspotify.dll is located but I still dont understand how to get the examples to work.
I have Code::Blocks installed but as soon as I try to import and run any of the .c files included in the /examples/ folder I get all kinds of error messages. The truth is that I am not even sure how to install libspotify and the documentation is absolutely non existent so for a beginner it is impossible to even have a chance at getting started.
Is there somebody out there who can do a simple walkthrough on how to install libspotify and get the examples up and running on a Win 7 (64-bit) machine?
The only thing I really want to do with libspotify is to be able to via a command prompt or something like that be able to queue a song in Spotify so I dont really care about the other parts. But I can probably solve that by myself as long as I can get an example up and running.
Sadly libspotify is not well-supported on Windows, in fact the example code won't even build because there is no Windows audio driver for them. Your best bet to just get up and running would be to use mingw, or linux in a VirtualBox environment.
I am using Intel(R) VTune(TM) Amplifier XE 2013 Update 5 (build 274450) for my linux application hotspot collect， but the report says the "[Outside any known module]" consume most of the time, so i want to get more info about the unknow module.
when i read the release notes of the vtune Amplifier, it says "List of hotspots may contain "Outside any known module" on systems with kernel older than 2.6.20 (200233501)", but my linux kernel is "2.6.32", any idea about this?
Check that your program is not generating code on the fly (i.e. is not JIT-ing). You may also want to switch grouping to "Module / Code Location / Call stack" and see which virtual addresses cannot be mapped by VTune to any known module.
I have been suffering from this issue in the past as well and it is very frustrating if you don't know why it is happening.
2 weeks ago I installed Ubuntu 13.04 and vtune update 14 and I was jumping from joy because I could see (again) what happened inside my code.
After doing some updates on my Ubuntu, vtune started to show your problem
I installed the kernel sources.. no help..
I reinstalled the driver, no help.
I reinstalled intel vtune.. no help.
And then I decided to run under root, and what do you know.. It works; no more 'Outside any known module'. I switched back to my regular user, it stopped working. I switched back to my root, and it works. So perhaps some kinds of access issue.
Maybe you could try this.
Probably you have some kernel hidden addresses by kptr_restrict, you ca review the value of "/proc/sys/kernel/kptr_restrict":
kptr_restrict = 0, kernel addresses are provided without limitations (recommended).
kptr_restict = 1, addresses are provided if the current user has a CAP_SYSLOG capability.
kptr_restrict = 2, the kernel addresses are hidden regardless of privileges the current user has.
You can use this option before running the trace:
sysctl -w kernel.kptr_restrict=0
More details here: https://software.intel.com/en-us/vtune-help-enabling-linux-kernel-analysis
Hope this helps!
We have a higher-end Win7-64 Dell precision workstation notebook with an i7, 8 gigs of ram, tons of hd space and running dedicated AMD graphics. The machine is about a month old. It was one of the highest-end we could get at the time.
What we're experiencing is when we run our WPF/SQL Server (local) app, it tends to hang and stall, sometimes completely crashing, but mostly just hanging until we force it to close. However, the exact same installer running in a VMware virtual machine running on that same machine runs flawlessly. Actually, the VM install runs better than a lot of native installs on other machines. It's very snappy with no hangs or hesitations at all. But again, same app, same installer running direct in the OS, and we're back to the issues above.
We've ran all Windows updates.... we've tried completely reinstalling everything... .NET frameworks, SQL Server, video drivers, even updated the BIOS and checked for rogue services but it still happens.
At first we thought it was Symantec AV's real-time protection because when we first shut that off, things started getting snappy again (and slowed down and froze when it auto-re-enabled itself furthering this hypothesis) but then it just started slowing down again, and more surprising, that same AV is running in the VM without issue! Checked the exceptions but there weren't any.
We even tried forcing WPF to run in software-render mode but again, nothing.
Now the odd thing is this only seems to be happening on this and a few other machines, but we can't seem to find anything in common except they're all running Win7 64-bit. As such, we have absolutely no idea where to start. And since most are hangs, not crashes, we can't even look at the crash reports.
So can anyone give us any idea what else we can look at? This is holding up us shipping a three-years-in-the-making major release of our software so to say this is a show-stopper would be an understatement. We've been stumped for about a month now and getting nowhere fast.
Found it!! Turns out there's a bug in .NET 4.0 regarding UI Automation and the changes MS introduced. Here's the info, and the fix! (Note: Even if you call MS, they will send you a link, but it's always a broken link. I managed to track this down manually.)
Note: Their article talks about a specific case that causes this behavior, but if you google around, you'll see tons of issues around hangs related to those DLLs. The latest is they're promising a fix in the .NET 4.5 runtime (from a MS post on this issue.)
Here's the KB article...
http://support.microsoft.com/kb/2484841/en-us
...and here is the actual hotfix.
http://archive.msdn.microsoft.com/KB2484841/Release/ProjectReleases.aspx?ReleaseId=5583
Apparently the VM didn't suffer from this. We weren't sure if the VM had the hotfix applied or not or if this only happens on non-virtualized machines. Still, this solved all of the issues and the app is now snappy again. (Man, was this fun to track down! Ugh!!)