Possible Memory Dump...To Client Browser (very technical in depth)

Preface: Using Phalcon 3.4.1 (I know they're on 3.4.4, but project was started when 3.4.1 was new) on PHP 7.0.30 (because) mounted on IIS 10.0, in Windows Server 2016 (64 bit) HOWEVER, the output is system agnostic as it was copied through SVN to another dev machine with the same results below.

I was testing selection methods for my models to get some JSON data from the database to the view. Suddenly, instead of the page, the response it starts sending is a phalcon error splash page informing me the controller it just processed 4 seconds ago will not load.

Some triaging later, it happens in my bootstrapper when I run "echo $app->handle()->getContent();". So I wrap it in a try/catch block with a constant echo message in the catch, and it instead returns (to the browser) most (except for the first ~200 bytes) of the controller code in question.

Further triaging leads us to believe it's just this one controller, as login stil works, and other lists work properly.

Outputting the exception message gives a generic "controller could not be loaded", while the stack trace is a small section of memory dump (presumably, it's random binary data that I'm not going to try and parse), the stack code is blank, and gthe stack message is simply "the X controller failed to load". The same as the phalcon error screen I get without the try/catch, just no pointers back to my bootstrapper (the handle application line above). Update since trying again just now, the exception message is also a binary dump, but smaller.

Things I have tried to resolve this:

• Removed a suspected magic variable name ($objectID) from procedures in the controller did not help.
• Removed a simple output from the view ({{ data }}), and replaced it with a constant test string, did not help.
• Commenting out the entire controller code did not help.
• Deleting the class contents did not help.
• Deleting the file itself (and then clearing the volt cache) did not help.
• Renaming the controller, view, action, and other variable names did not help.
• Increasing system RAM from 4GB to 16 GB did not help.
• UPDATE HERE: Turning off the volt engine did not help. This is not a volt problem.
• Address does use a recursive function, but var_dumps at the beginning of our Action call reveal it's not even getting that far.
• Manual route defined in router definitions have not helped.
• My dispatcher has an event listener attached to it called Permissions, and it operates normally, except for this page. This page is not forwarding through dispatcher - a die statement in my forwarded event reveals it is not even hitting this function. Created as:

  $di->set('dispatcher', function () use ($di) {
  $events_manager = $di->getShared('eventsManager');
  // Custom ACL class
  $permission = new Permission();
  // Listen for events from the $permission class
  $events_manager->attach('dispatch', $permission);
  $dispatcher = new Dispatcher();
  $dispatcher->setEventsManager($events_manager);
  return $dispatcher;
  });
  public function beforeExecuteRoute(Event $event, Dispatcher $dispatcher) {
      die('Permissions reached!');

  (Apologies, don't know how to change the color of that block)

• This message is never displayed for my page.

Symptoms: The view is never compiled into volt's output cache directory.

What code would you need to help me resolve this? The page request needs to return something (under whatever name will work) but right now, it seems that the files simply refuses to load properly.